# VISTA Link AI 智能体综合解决方案（基于项目多文档）
> 文档定位：产品、业务、设计、研发共同评审用的综合解决方案。编制日期：2026-08-22业务闭环复核：2026-08-23（依据钉钉团队空间中的主 PRD、AI PRD、评审纪要及统计定义重新校正）需求基线：[主 PRD V0.248](https://alidocs.dingtalk.com/i/nodes/N7dx2rn0Jb66LrvBTZkMPZN4JMGjLRb3)、[AI 与智能体 PRD V1.6](https://alidocs.dingtalk.com/i/nodes/o14dA3GK8g66L4qdTEXye0e9J9ekBD76)说明：主 PRD 与 AI PRD 是现阶段唯一的正式需求边界；本项目其他文档用于补充场景、产品决策、页面设计、技术实现和未来路线，不能直接替代正式 PRD。   

---

## 0\. 阅读规则：四类状态不能混用

本文对每项能力使用以下状态。这里的“采用”，表示方案认为该方向合理，并不代表未经评审就已经成为正式需求。

| 标记 | 含义 | 能否直接开发 |
|------|------|------------------|
| **【正式 PRD】** | 主 PRD V0.248 或 AI PRD V1.6 已有明确对象、流程、权限或验收要求 | 可以进一步拆分设计与研发任务 |
| **【采用，需改 PRD】** | 项目其他文档已经给出较完整、且与产品方向一致的方案 | 必须先补充或修改 PRD，再进入开发排期 |
| **【实施设计】** | 不改变业务范围的架构、交互、可靠性或工程实现建议 | 可随正式需求进入技术设计，但需产研评审 |
| **【暂缓/不采用】** | 当前数据、边界或价值不足，或会使 Link 变成重型 CRM、交易系统 | 不进入本阶段范围 |

一条总原则：
> 正式 PRD 决定“做不做”；其他文档帮助回答“为什么做、怎么做、先做什么、做到什么程度”。   

---

## 1\. 综合结论

### 1.1 最终产品定位

建议将 VISTA Link 定义为：
> **面向日本新建公寓销售，以项目内容与客户专属页面为基础，以客户自主浏览和现场接待事实为上下文，以可确认的 AI 工作草稿和 SMS 行动为输出的轻量销售协同平台。**   

更简洁地说：
> **VISTA Link = 新建公寓专业内容层 \+ 客户连续服务工作区 \+ B 端 AI 助手 \+ 受控行动层。**   

它不需要复制一套完整 CRM，也不需要成为合同、贷款、房源销控或交易系统。它应守住五项核心资产：
1. 项目级客群标准方案、主题内容包、必讲项和风险边界；
2. 项目内容、素材、页面及版本关系；
3. 客户专属页面与每次访问的连续状态；
4. 带有内容上下文、来源和版本的行为事件；
5. 有依据、可修改、经确认并可追溯的 AI 工作结果。

### 1.2 经过钉钉资料复核的完整业务闭环

复核后需要先纠正一个概念：**VISTA Link 的主业务闭环不是“内容 → AI → SMS/预约 → 交易结果”的单线流程。** 正式 PRD 定义的是销售围绕页面、现场讲解、客户自主访问和再次推荐形成的连续服务；SMS、预约系统和交易系统是不同阶段接入的行动或权威结果支路。

钉钉中的主 PRD 与 AI PRD 合并后，共有七类销售工作：接待前准备、已有客户现场接待、临时客户现场接待、远程咨询与首次发送、到访后发送资料、根据访问继续推荐、购买申请与签约状态更新。完整关系如下。
```mermaid
flowchart TB
    subgraph ENTRY["一、三个真实业务入口"]
        E1["已有客户到访\n已预约或已建档"]
        E2["临时客户到访\n未预约或尚未建档"]
        E3["远程咨询\n电话、LINE、邮件或资料请求"]
    end

    subgraph PREP["二、客户与内容准备"]
        P0["项目客群方案库\n通用及主要客群、内容包、必讲与风险项"]
        P1["查找或创建客户"] --> P2{"首次接触还是已进入追踪？"}
        P2 -->|"首次接触"| P3["直接选择客群标准方案；\n无法判断时使用通用方案"]
        P2 -->|"已进入追踪"| P4["读取明确反馈、有效自主访问、\n历史讲解和未解决问题"]
        P4 --> P5["AI准备个体跟进、\n后续页面或复访方案"]
        P3 --> P6["使用标准页面和内容顺序"]
        P5 --> P6["销售检查并确认个体方案"]
        P0 --> P3
        P0 --> P5
    end

    subgraph CONTACT["三、接待或首次沟通"]
        O1["已有客户现场讲解"]
        O2["临时讲解"] --> O3["结束后创建或选择客户，\n关联、纠错或标记无效记录"]
        R1["远程说明并取得客户访问地址"]
        O1 --> O4["销售确认客户真实反馈、\n条件变化和未解决问题"]
        O3 --> O4
    end

    subgraph FOLLOW["四、页面提供与客户自主访问"]
        F1["根据现场反馈或再次建议\n选择/制作后续页面并绑定客户"] --> F2{"实际发送通道"}
        F2 -->|"正式PRD当前做法"| F3["销售在LINE或邮件等外部工具发送"]
        F2 -->|"目标扩展"| F4["销售确认后由Link发送SMS"]
        F3 --> F5["客户打开地址并完成身份识别"]
        F4 --> F5
        F5 --> F6["客户自主浏览"]
        F6 --> F7["生成独立访问记录和历史内容快照"]
    end

    subgraph NEXT["五、再次推荐与下一轮服务"]
        N1["销售或AI按可靠事实整理\n询问方向和资料建议"] --> N2{"下一步决定"}
        N2 -->|"再次提供页面"| N3["准备新的页面或访问地址"]
        N2 -->|"再次到访"| N4["进入下一次接待准备"]
        N2 -->|"预约协调"| N5["外部预约或日历系统处理"]
    end

    subgraph RESULT["六、真实业务结果与状态"]
        X1["实际沟通、预约、到访、\n购买申请或合同结果"] --> X2["人员或权威系统确认事实"]
        X2 --> X3["销售确认后手动更新客户状态"]
        X3 --> X4{"继续跟进？"}
        X4 -->|"是"| X5["回到下一轮准备或推荐"]
        X4 -->|"否"| X6["签约或未签约"]
    end

    E1 --> P1
    E3 --> P1
    P6 --> O1
    P6 --> R1
    E2 --> O2
    O4 --> F1
    R1 --> F2
    F7 --> N1
    N3 --> F1
    N4 --> P2
    N5 --> X1
    X5 --> N1
    N2 -->|"发生明确业务结果"| X1
```

这张图中必须坚持四个分离：

| 需要分开的闭环 | 负责回答的问题 | 不能混入的内容 |
|---------------------|---------------------|---------------------|
| 内容底座闭环 | 页面和素材是否可用、已发布、版本正确 | 不能把草稿或过期资料当成可发送内容 |
| 销售服务闭环 | 本次从哪里开始、展示/发送了什么、客户之后做了什么、下一次如何继续 | 不能漏掉临时客户、远程咨询和再次推荐 |
| AI 工作闭环 | 读取什么依据、生成什么草稿、谁确认、写回什么 | AI 判断不能直接成为预约、到访或签约事实 |
| 外部结果闭环 | 预约、到访、购买申请和合同等真实结果来自哪里 | Link 不重复建设完整预约、贷款、合同和交易系统 |

相对上一版图，本次补回并纠正了以下节点：
1. 补回“已有客户、临时客户、远程咨询”三个业务入口；
2. 补回客户查找/创建、首次客群方案选择，以及进入追踪后的历史读取和个体页面准备；
3. 补回临时讲解结束后的客户关联、纠错和无效记录处理；
4. 补回“到访后重新整理并发送资料”，不是现场讲解结束后直接进入预约；
5. 补回客户身份识别、自主访问、独立访问记录和历史内容快照；
6. 补回“根据访问再次推荐”，形成页面与客户关系的循环；
7. 补回购买申请至签约/未签约的**状态回写**，但外部业务表单和合同仍不进入 Link；
8. 将 SMS 改为目标扩展通道，将预约与交易改为外部权威结果支路，不再把它们画成每个客户都必须经过的主链路。
9. 增加项目级客群方案库：首次接触直接使用客群标准方案；客户产生真实反馈和行为、进入追踪后，才生成个体跟进或复访方案。

### 1.3 功能边界结论

| 能力 | 综合决策 | 说明 |
|------|------------|------|
| 项目级客群标准方案与主题内容包 | 【采用，需改 PRD】 | 项目预先配置通用及主要客群方案、默认内容、必讲项和风险项；首次接触使用标准方案，进入追踪后才按个体制定方案 |
| 浏览器内 B 端 AI 助手 | 【正式 PRD】 | 读取当前项目与对象上下文，生成草稿，写入前确认 |
| 客户、素材、页面、访问、追踪、仪表盘等 Agent 能力 | 【正式 PRD】 | 以 AI PRD V1.6 的工具和权限为准 |
| 区分客户自主浏览与销售现场演示 | 【正式 PRD】 | 实施时必须确保不能把销售点击误判为客户兴趣 |
| 接待准备、内容摘要、接待后纪要草稿 | 【正式 PRD】 | 事实、判断、建议必须分层并可追溯 |
| SMS 单客发送和发送结果回流 | 【采用，需改 PRD】 | 推荐作为第一个行动扩展，先逐次人工确认 |
| 预约协调和预约结果确认 | 【采用，需改 PRD】 | Link 可协调；“已确认”必须来自权威预约系统或人员 |
| 分享记录、渠道和活动绑定 | 【采用，需改 PRD】 | 是后续归因、ROI 的数据基础 |
| 渠道归因 | 【采用，需改 PRD】 | 先首次/末次触达，保留全部原始触点 |
| ROI | 【采用，需改 PRD】 | 属于后置能力；成本、收入、归属范围和口径版本完整后再建设 |
| 自动意向评分 | 【采用，需改 PRD】 | 属于后置能力；先做解释型信号与规则，后做校准评分；不得黑箱化 |
| 完整销售任务系统 | 【暂缓/不采用】 | 只保留与内容、接待和行动相关的轻量待办或外部同步 |
| 完整预约、认购、签约和交易管理 | 【暂缓/不采用】 | Link 记录必要结果，流程由 CRM/预约/交易系统负责 |
| 独立 AI 审核中心 | 【暂缓/不采用】 | 审核能力保留，嵌入 AI 任务中心、客户详情和发送确认卡 |
| C 端开放式 AI 聊天 | 【暂缓/不采用】 | 当前只做 B 端，C 端展示确定、已发布、可控内容 |
| 任意数据库写入式 Agent | 【暂缓/不采用】 | 属于禁止性边界；Agent 只能调用有限、强类型、受权限与策略控制的工具 |

---

## 2\. 本方案采用了哪些项目文档

### 2.1 文档采用映射

| 来源文档 | 主要输入 | 本方案如何采用 | 状态处理 |
|------------|------------|---------------------|------------|
| [AI 原生产品定义与 SMS 行动平台方案](./VISTA_Link_AI原生产品定义与SMS行动平台方案_整合稿.md) | AI 原生四层架构、SMS 优先、首个行动 MVP、系统/AI/人员边界 | 作为产品定位、SMS 行动层和统一业务对象的主要来源 | SMS 等超出正式 PRD 的部分标记“需改 PRD” |
| [日本新建公寓销售场景下的 AI 后台助力方案](./VISTA_Link_日本新建公寓销售场景下的AI后台助力方案.md) | 接待连续性、客户条件、未解决问题、重复来访、证据优先级 | 作为日本业务场景、页面信息结构和 AI 介入时点的主要来源 | 独立审核中心不采用；改为嵌入式审核 |
| [AI 驱动产品设计与轻量化操作方案](./VISTA_Link_AI驱动产品设计与轻量化操作方案.md) | 三问工作台、3 次点击、模型网关、可解释/可纠正、风险分级 | 作为销售端交互原则、模型路由、证据结构和风险控制来源 | 与正式 PRD 冲突的自动发送/评分按扩展处理 |
| [四项薄弱能力提升方案](./VISTA_Link四项薄弱能力提升方案.md) | 跟进、归因、到访/交易结果、外部系统集成及建设依赖 | 作为分享记录、结果模型、统一接口层和实施顺序来源 | 完整任务/交易模块收缩为轻量记录或外部系统连接 |
| [功能切入与简化操作方案](./VISTA_Link功能切入与简化操作方案.md) | 功能嵌入现有页面、一个主要动作、最少输入 | 作为客户详情、分享页、任务确认卡的交互设计来源 | 不新增四套孤立一级菜单 |
| [AI 到场方案与 PRD 对照分析](./VISTA_Link_AI到场方案与PRD对照分析.md) | PRD 与延展的状态划分、Link 与 CRM/预约/交易边界 | 作为范围冲突裁决和 PRD 变更判断依据 | 用现行 V0.248/V1.6 替代历史版本号 |
| [产品整改任务书](./VISTA_Link产品整改任务书.md) | 数据隔离、深层链接、页面/素材版本、状态模型、审计等基础问题 | 作为 AI 上线前的数据可信度和产品基础门槛 | 基础问题未通过时不扩大自动执行 |
| [PRD 完整复核与重构调整建议](./VISTA_Link_PRD完整复核与重构调整建议.md) | 从分享、行为到行动和结果的服务流；基础口径问题 | 作为依赖关系、验收顺序和产品主线来源 | 讨论稿能力不直接视为正式需求 |
| [日本竞品影响与产品应对建议](./VISTA_Link_日本竞品影响与产品应对建议_2026.md) | KASIKA、ROOV、Digima、Facilo 等企业行为；Link 防守位置 | 作为差异化定位、接口战略和 12 个月优先级来源 | 不按竞品功能表盲目扩张 |
| [浏览器端多租户 AI 智能体详细解决方案](./VISTA_Link_浏览器端多租户AI智能体_详细解决方案.md) | 浏览器 Agent、多租户、任务、工具策略网关、队列、容量、可靠性 | 作为本方案的工程实施底座 | 本文补充业务与产品整合，不重复替代底层详细设计 |
| [跨项目继续工作交接摘要](./VISTA_Link_跨项目继续工作交接摘要.md) | 已确认方向、历史冲突、待决策项 | 用于防止历史讨论稿被误当成正式 PRD | 以最新 PRD 和本次综合判断为准 |

### 2.2 冲突内容如何处理

| 文档间冲突 | 处理决定 |
|---------------|------------|
| 有的文档建议建立独立“AI 审核中心”，AI PRD 当前不纳入独立审核中心 | 保留审核对象、风险分级和审计记录；入口嵌入 AI 任务中心、客户详情及操作确认卡 |
| 有的整改稿建议建设完整跟进任务、预约和交易模块，后续定位要求不做重型 CRM | Link 仅建设“与内容和接待直接相关的轻量行动/结果对象”；完整工作流连接外部系统 |
| 有的文档把高意向评分放在第二阶段，有的文档明确先不做黑箱评分 | 第一阶段只做事实信号、规则提示和接待准备；有真实结果后再做可解释评分 |
| 用户希望最终建设 ROI，但若先做会缺少成本与成交数据 | 产品方向保留，实施顺序后置到身份链、触点、成本、权威结果完整之后 |
| 主 PRD 出现浏览器 AI 入口，AI PRD 的历史首批范围曾不含内置 Web Agent | 使用功能开关和分阶段试点；以发布时双方更新后的统一版本为准 |

### 2.3 本次钉钉目录复核与直接来源

本次重新读取了团队空间中的 [VISTA Link 文件夹](https://alidocs.dingtalk.com/i/nodes/gwva2dxOW4ZZX6qPckRjZgMaJbkz3BRL)，并以团队正式文档优先、个人分析稿辅助解释。业务闭环的直接依据如下。

| 钉钉来源 | 本次采用的章节或结论 | 对闭环的影响 |
|------------|------------------------------|------------------|
| [VISTA Link 产品需求文档（最新版，V0.248）](https://alidocs.dingtalk.com/i/nodes/N7dx2rn0Jb66LrvBTZkMPZN4JMGjLRb3) | §1.7 总体流程、§2.2 销售人员工作流、§7.1.1 销售场景验收、§8.4 企业试用验收 | 确认现场接待、页面发送、客户自主访问、再次推荐和状态手动更新是正式主线 |
| [VISTA Link AI 与智能体产品需求文档（最新版，V1.6）](https://alidocs.dingtalk.com/i/nodes/o14dA3GK8g66L4qdTEXye0e9J9ekBD76) | §2.6 七类销售场景、§2.7 固定流程、§16.1 接待前准备、§16.8 讲解后准备页面 | 补齐接待前准备、临时客户、远程咨询、到访后发送、再次推荐及人工审核点 |
| [2026-07-30 VISTA Link B 端需求评审会议纪要](https://alidocs.dingtalk.com/i/nodes/Obva6QBXJw44Knv2cM5Pw3ym8n4qY5Pr) | §3.3 客户与分享关系、§3.5 页面与分享、§3.6 客户追踪 | 确认“复制链接不等于已发送”，客户识别和真实访问必须单独记录 |
| [VISTA Link B 端统计需求定义](https://alidocs.dingtalk.com/i/nodes/dpYLaezmVNAA9Dp2iK2q5E33WrMqPxX6) | 客户追踪、营销统计、现场讲解与自主访问的记录口径 | 确认现场讲解与客户自主访问不得合并统计 |
| [VISTA Link AI 原生产品定义与 SMS 行动平台方案（整合稿）](https://alidocs.dingtalk.com/i/nodes/mExel2BLV5aaKAqwupRyznZ4Vgk9rpMq) | §9 SMS 平台、§11 MVP、§12 路线、§14 PRD 调整 | 将 Link 原生 SMS 定义为目标扩展，但不反向改写当前正式 PRD 的外部发送边界 |
| [日本新建公寓销售场景 AI 方案（版本边界标注版）](https://alidocs.dingtalk.com/i/nodes/2Amq4vjg89RRDA9BsxGjvj0RW3kdP0wQ) | 来访准备、现场接待、多次来访、资金与申请准备 | 补充日本业务中的客户条件变化、未解决问题和多次来访连续性 |

复核时采用的优先级是：**正式主 PRD和正式 AI PRD ＞ 团队评审纪要与统计定义 ＞ 已标注版本边界的场景方案 ＞ 个人分析与后续产品提案。** 后续产品提案可以推动改 PRD，但不能悄悄替换当前正式边界。

---

## 3\. 日本新建公寓销售场景的核心问题

### 3.1 Link 需要解决的不是“更多数据”，而是服务连续性

日本新建公寓销售通常不是一次浏览、一次到访就完成。客户会经历线上了解、资料比较、预约、首次到访、家庭讨论、再次到访、资金与申请准备。问题往往不是没有资料，而是：
- 销售不知道客户已经自主看过什么；
- 现场又重复讲解客户已经知道的内容；
- 客户明确表达的预算、户型、时间等条件散落在问卷、浏览和人工记录中；
- 本次未回答的问题没有成为下一次接待准备；
- 第二次到访时无法快速理解客户条件发生了什么变化；
- 系统把销售现场点击误当成客户自主兴趣；
- 管理者看到访问量，却看不到接待是否准备充分、问题是否得到解决。

因此，AI 的第一价值不是“判断谁一定会买”，而是：
> **让本次接待更完整，让下一次接待能够从上次结束的位置继续。**   

### 3.2 日本场景的推荐服务流
```mermaid
flowchart TB
    A{"客户从哪里进入？"}
    A -->|"远程咨询/已有客户"| B1["查找或创建客户"]
    A -->|"临时客户到访"| B2["使用通用客群方案开始临时讲解"]
    B1 --> C{"客户是否已进入追踪？"}
    C -->|"否：首次接触"| D["选择客群标准方案；\n无法判断时使用通用方案"]
    C -->|"是：已有可靠个体事实"| E["AI生成个体跟进、\n后续页面或复访方案"]
    D --> F{"远程还是现场？"}
    E --> F
    F -->|"远程"| G["取得客户访问地址"]
    F -->|"现场"| H["现场接待与内容演示"]
    B2 --> I["结束后关联客户"]
    I --> J["销售确认客户反馈"]
    H --> J
    J --> K["纪要、条件变化和未解决问题草稿"]
    K --> L["销售确认事实，客户进入/更新追踪"]
    L --> M["准备个体后续页面、消息或复访方案"]
    G --> N{"发送方式"}
    M --> N
    N -->|"当前正式范围"| N1["销售在外部LINE/邮件等工具发送"]
    N -->|"目标扩展"| N2["Link确认后发送SMS"]
    N1 --> O["客户身份识别与自主浏览"]
    N2 --> O
    O --> P["记录访问内容、次数、时长和明确动作"]
    P --> Q["更新个体跟进方案"]
    Q --> R{"继续方式"}
    R -->|"再次发送"| M
    R -->|"再次来访"| E
    R -->|"进入购买申请/合同"| S["外部业务完成，销售手动回写状态"]
```

这一服务流不要求每个客户都先预约，也不要求每个客户都进入 SMS。预约可以是已有客户来访的来源之一，也可以是再次推荐后的外部动作；SMS只是页面提供的一种目标通道。**真正不可缺少的是“本次接触—客户之后的自主行为—下一次销售准备”能够连续衔接。**

### 3.3 AI 只在三个时点主动介入
1. **客户进入追踪后**：客户已经产生明确反馈、有效自主浏览或历史接待记录时，才按个体生成跟进/复访方案；
2. **接待后**：对比客群标准方案与现场实际情况，生成待确认纪要、未解决问题和后续页面/SMS 草稿；
3. **追踪信息变化时**：发现资料版本更新、客户条件变化、结论过期或事实冲突。

首次咨询和首次接待直接使用预先制作的客群标准方案，不要求 AI 在接待前为单个客户重新生成一套方案。其他能够通过一次查询、一次勾选或固定规则完成的工作，也不调用模型。

### 3.4 房地产销售应采用“客群标准方案—现场适配—追踪后个性化”

售楼接待具有较强的重复结构。项目概况、交通、户型、样板间、眺望、日照、公共设施、价格费用和购买流程等基础内容，应在项目上线时就按主要客群做好标准方案。首次咨询或首次接待直接使用对应客群方案，**不需要在接待前再为单个客户生成一套方案**。

只有客户完成首次接触，产生了明确表达、有效自主浏览、现场讲解或后续业务结果，进入客户追踪后，系统才基于个体事实制定后续页面、沟通和复访方案。

#### 3.4.1 建议预先建立的客群方案

每个项目可以根据实际客群选择 4—6 类，不要求全国或所有项目使用同一套。第一版建议从以下需求导向的客群中选择：

| 客群标准方案 | 默认关注重点 | 默认内容包 |
|------------------|------------------|---------------|
| 通用/尚未判断 | 建立项目基础认知 | 项目概览、位置交通、代表户型、样板间/VR、公共设施和费用基础 |
| 通勤便利型 | 车站、线路、工作地通勤和生活便利 | 区位交通、地图、周边生活、代表户型和来访入口 |
| 家庭空间型 | 房间数量、面积、收纳、育儿和长期居住 | 户型比较、室内空间、公共设施、周边环境和生活动线 |
| 预算费用型 | 总价、月度支出、管理费、修缮费和资金安排 | 价格费用、户型价差、费用说明和可使用的官方资金资料 |
| 居住品质型 | 眺望、日照、朝向、设计、设备和公共空间 | 眺望日照、样板间、设备规格、共用部和设计说明 |
| 资产配置型 | 区位价值、出租、转售和长期持有 | 区位、供需、户型流通性及经批准的资产说明；不得由 AI 承诺收益 |

客群方案不是客户的永久标签。首次接触时只是选择一套合适的标准介绍路径；如果无法判断，直接使用“通用/尚未判断”，不强行归类。

#### 3.4.2 每套客群方案预先包含什么

| 配置内容 | 说明 |
|------------|------|
| 默认内容和顺序 | 该客群通常先看什么、后看什么 |
| 标准页面/素材包 | 已发布且当前有效的项目页面、Widget 和素材 |
| 标准提问 | 用于确认客户是否确实属于该需求方向，不把推测写成事实 |
| 必讲项 | 当前项目要求必须说明的费用、限制、交付或其他事项 |
| 风险边界 | 价格、折扣、贷款、收益、交付和合同等不得自由承诺的内容 |
| 切换规则 | 客户现场关注方向明显变化时，可以切换到另一客群方案或追加一个主题包 |

#### 3.4.3 正确业务流程
```mermaid
flowchart LR
    A["项目预先配置\n客群标准方案、内容包、必讲与风险项"] --> B["首次咨询或首次到访"]
    B --> C{"选择客群方案"}
    C -->|"可以判断"| D["直接使用对应客群标准方案"]
    C -->|"暂时无法判断"| E["使用通用方案"]
    D --> F["现场或远程沟通"]
    E --> F
    F --> G["按客户真实反应切换方案、追加或跳过内容"]
    G --> H["记录实际展示、客户明确表达和未解决问题"]
    H --> I["客户离场/首次沟通结束"]
    I --> J["客户进入追踪"]
    J --> K["结合明确反馈、有效访问和历史记录"]
    K --> L["AI生成个体跟进、后续页面或复访方案"]
    L --> M["销售确认并执行"]
    M --> N["新的行为和业务结果回流"]
    N --> K
```

三个阶段的责任是：
- **首次接触前**：项目团队提前把客群标准方案做好，销售只选择方案，不为单个客户做 AI 定制；
- **首次接触中**：销售根据现场或远程沟通实时切换、追加或跳过内容，系统只记录实际发生的事实；
- **进入追踪后**：AI 才根据该客户已经产生的可靠事实生成个体跟进、后续页面和复访方案，销售确认后执行。

#### 3.4.4 首期保持简单

第一版不要建设复杂的多级客群树。每个项目只需要：
1. 配置一个通用方案和 4—5 个主要客群方案；
2. 每套方案维护默认内容顺序、标准提问、必讲项和风险边界；
3. 首次接触只选择一个客群方案，必要时现场追加一个主题包；
4. 客群选择只是本次接待路径，不自动写成已确认客户属性；
5. 没有足够信息时使用通用方案，不要求销售猜测客户类型；
6. 客户产生明确反馈或有效行为并进入追踪后，才创建个体方案；
7. 个体方案不自动修改项目客群模板；只有多个客户反复出现同类变化时，才提示管理者评估模板更新。

---

## 4\. 用户角色与核心任务

| 角色 | 核心任务 | AI 提供的帮助 | 不能替代的责任 |
|------|------------|------------------|---------------------|
| 一线销售/接待人员 | 准备接待、现场说明、跟进客户 | 客户摘要、接待卡、内容组合、日文 SMS 草稿、问题清单 | 确认客户表达、发送对外内容、作出业务承诺 |
| 销售经理 | 查看异常、待确认、高风险内容与服务质量 | 汇总未解决问题、超期事项、团队数据质量 | 审核高风险内容、处理例外和权限 |
| 内容运营 | 管理项目资料、素材、页面和版本 | 检查缺失/过期/引用影响，生成页面草稿 | 确认发布内容、价格政策和生效版本 |
| 项目管理员 | 管理成员、权限、渠道、连接器和模型策略 | 生成配置建议、同步异常摘要 | 配置权限、密钥、额度和外部主数据源 |
| 外部智能体 | 在授权范围内读取或调用 Link 工具 | 跨系统理解与编排 | 不得绕过 Link 权限、确认和审计 |
| 客户 | 浏览已发布页面、接收确认后的消息 | 当前不直接使用开放式 AI | 决定是否回复、预约和继续了解 |

---

## 5\. 产品形态：浏览器内的 B 端智能体

### 5.1 全局入口

【正式 PRD】在主系统右下角提供 AI 入口。打开后默认获得：
- 当前租户；
- 当前项目；
- 当前页面或对象类型；
- 当前对象 ID；
- 当前用户与实时权限；
- 用户主动选中的客户、素材、页面或访问记录。

AI 不应默认读取整个租户数据，更不能把其他项目数据带入当前回答。

### 5.2 侧边面板结构
```mermaid
flowchart TB
    A["AI助手侧边面板"] --> B["当前范围<br/>项目 / 客户 / 页面 / 素材"]
    A --> C["对话与任务输入"]
    C --> D["结论卡<br/>AI整理结果"]
    D --> E["依据卡<br/>系统事实 / 资料版本 / 原始记录"]
    D --> F["草稿区<br/>页面 / 摘要 / 接待卡 / SMS"]
    F --> G["变更对比<br/>现有版本 vs 准备写入"]
    G --> H{"风险级别"}
    H -->|低风险| I["保存内部草稿"]
    H -->|需要确认| J["销售确认"]
    H -->|高风险| K["负责人审核"]
    I --> L["任务与审计记录"]
    J --> L
    K --> L
```

### 5.3 三层结果展示

每个重要输出固定使用三层结构：
1. **结论**：用户现在最需要知道或处理什么；
2. **依据**：时间、次数、来源、客户原话、资料版本和置信度；
3. **原始记录**：可以跳到对应访问、页面、问卷、现场记录或资料原文。

示例：
```text
【系统事实】
客户 7 天内自主访问 3 次，重复查看 A 户型和费用页面。

【AI 判断】
客户可能仍在比较月度支出，置信度 82%。

【AI 建议】
发送最新费用说明，并在下次接待中确认预算范围。

[查看 3 条访问记录] [查看费用资料 V2026.08] [纠正判断]
```

### 5.4 AI 任务中心，而非独立审核中心

任务中心统一承载：
- 正在运行；
- 等待用户补充；
- 等待销售确认；
- 等待负责人审核；
- 执行中；
- 已完成；
- 失败或需要重试；
- 已取消。

审核只是任务状态和风险处理方式，不再新建一套与客户、内容、发送完全分离的一级导航。

---

## 6\. 页面与信息结构方案

### 6.1 项目总览

首页不堆放大量统计卡片，优先回答：
1. 今天需要准备哪些接待？
2. 首次接触采用哪个客群标准方案，哪些追踪客户已经生成个体方案？
3. 哪些 AI 草稿或对外内容等待确认？
4. 哪些客户存在未解决问题、资料过期或数据冲突？

推荐区域：

| 区域 | 内容 | 主要动作 |
|------|------|------------|
| 首次接触方案 | 客群标准方案、默认内容、标准提问、必讲项和风险项 | 选择/切换方案 |
| 追踪客户方案 | 客户、历史反馈、已看内容、未解决问题和个体跟进/复访方案 | 查看并确认 |
| 客群方案维护 | 通用及主要客群的内容包、必讲项、风险项和版本 | 预览/维护 |
| 待确认 | 页面草稿、纪要、SMS、高风险回复 | 检查并确认 |
| 需要补齐 | 缺少负责人、来源、有效资料或权威结果 | 指派/补齐 |
| 未解决问题 | 客户问题、责任人、期限、是否需专业人员 | 查看并处理 |
| 数据质量 | 身份未关联、外部/现场来源不明、资料版本冲突 | 修正来源 |

### 6.2 客户列表

默认按“需要处理”而不是按创建时间排序，显示：
- 当前销售/接待阶段；
- 最近关键事实；
- 是否有待确认信息；
- 是否有未解决问题；
- 下一次来访或建议处理时间；
- 资料/判断是否已过期；
- 当前负责人。

### 6.3 客户详情：统一工作区
```mermaid
flowchart TB
    A["客户详情统一工作区"]
    A --> B["当前状态层"]
    A --> C["AI协同层"]
    A --> D["事实与历史层"]
    A --> E["行动层"]

    B --> B1["当前客户条件"]
    B --> B2["来源 / 日期 / 确认状态"]
    B --> B3["历史变化与冲突"]

    C --> C1["接待准备卡"]
    C --> C2["纪要草稿"]
    C --> C3["未解决问题"]
    C --> C4["首次客群方案、现场变化与追踪后的个体方案"]

    D --> D1["自主浏览"]
    D --> D2["现场演示"]
    D --> D3["问卷与客户表达"]
    D --> D4["分享、消息和权威结果"]

    E --> E1["推荐下一步"]
    E --> E2["检查并发送"]
    E --> E3["确认预约结果"]
    E --> E4["统一时间线与审计"]
```

每个阶段只突出一个主要按钮：
- 接待前：“查看接待准备”；
- 接待后：“确认本次纪要”；
- 有补充内容：“检查并发送”；
- 有预约意向：“确认预约结果”；
- 有数据冲突：“核实事实”。

### 6.4 内容与页面库

除原有项目、分类、标签、状态和版本外，建议补充：
- 适用销售阶段；
- 适用客户条件；
- 所属标准主题内容包和默认展示顺序；
- 是否为客群标准方案必讲项、可选项或禁止自动推荐项；
- 外部分享/现场演示适用范围；
- 资料版本与生效时间；
- 是否涉及价格、优惠、交付或合同等高风险信息；
- 引用该素材的已发布页面；
- 更新后受影响页面和客户。

AI 只能向外推荐已发布且当前有效的内容；内部草稿必须明确标识，不得自动发送。

### 6.5 行为时间线

每个事件必须标明来源：

| 来源类型 | 示例 | 能否直接解释为客户兴趣 |
|------------|------|---------------------------------|
| 客户自主行为 | 客户通过专属链接浏览、比较、下载 | 可以作为行为证据，但不能单独等于购买意向 |
| 员工现场演示 | 销售在接待现场打开户型、费用资料 | 不能自动解释为客户兴趣 |
| 客户明确表达 | 问卷、经销售确认的客户原话 | 高优先级证据 |
| 系统事件 | 页面发布、素材更新、消息送达、同步完成 | 仅表示系统状态 |
| 外部权威结果 | 预约系统确认、CRM 到访、交易系统结果 | 作为业务事实 |

---

## 7\. 证据、事实和推断模型

### 7.1 三类信息必须分开保存

| 类型 | 示例 | 责任 |
|------|------|------|
| 系统事实 | 某时访问某页面；SMS 已送达；预约系统返回已确认 | 系统或权威外部系统 |
| 客户表达 | “预算约 6,000 万日元”“希望 3LDK” | 客户表达；AI 可提取，但需人员确认 |
| AI 推断 | “可能关注月供”“本次应重点说明交通” | AI 生成；显示依据、置信度、版本和失效时间 |

### 7.2 证据优先级
```text
客户明确条件
    > 现场经员工确认的反馈
    > 客户自主浏览行为组合
    > 销售现场演示点击
```

当证据冲突时，不允许 AI 静默覆盖。系统应展示：
- 哪两条信息发生冲突；
- 各自来源与时间；
- 哪条是当前有效事实；
- 是否需要销售在下次接待中确认。

### 7.3 AI 结论最少字段

| 字段 | 说明 |
|------|------|
| conclusion\_type | 摘要、条件、变化、风险、行动建议等 |
| conclusion | 结构化结论 |
| confidence | 置信度；低风险摘要也要能说明不确定性 |
| evidence\_ids | 对应访问、问卷、资料、现场记录或外部结果 ID |
| source\_versions | 使用的页面、素材、政策或规则版本 |
| model*strategy*version | 模型、提示模板、规则与路由版本 |
| generated*at / expires*at | 生成与失效时间 |
| user\_decision | 未处理、确认、修改、驳回 |
| corrected\_value | 人工修正结果 |
| tenant*id / project*id | 强制租户和项目范围 |

---

## 8\. 七个正式销售流程、两个扩展流程与治理流程

本节按钉钉正式 AI PRD §2.6 的七类销售场景重新组织。前七项属于正式业务主线；SMS 和预约连接是目标扩展；管理者复核是治理流程，不是客户必须经过的业务节点。

| 编号 | 场景 | 当前状态 | 闭环中的作用 |
|------|------|------------|------------------|
| A0 | 首次客群标准方案 | 【采用，需改 PRD】 | 项目预先维护客群标准方案；首次接触直接选择对应方案，无法判断时使用通用方案 |
| A | 追踪客户个体准备 | 【正式 PRD】 | 客户进入追踪后，才将明确反馈、有效行为和历史事实变成个体方案 |
| B | 已有客户现场接待 | 【正式 PRD】 | 记录真实讲解并承接客户反馈 |
| C | 临时客户现场接待 | 【正式 PRD】 | 允许先接待、后识别和关联客户 |
| D | 远程咨询与首次发送 | 【正式 PRD】 | 覆盖未到访客户的首次页面提供 |
| E | 到访后发送资料 | 【正式 PRD】 | 把现场反馈转为客户回家后继续看的内容 |
| F | 根据访问继续推荐 | 【正式 PRD】 | 把自主访问变成下一次询问或内容准备 |
| G | 购买申请与签约 | 【正式 PRD】 | 只依据外部明确结果手动更新客户状态 |
| H | Link 原生 SMS | 【采用，需改 PRD】 | 将一个外部发送通道升级为可审计的系统行动 |
| I | 预约系统连接 | 【采用，需改 PRD】 | 连接预约意向与权威确认，不建设完整预约系统 |

### 8.1 流程 A0/A：首次使用客群方案，追踪后进行个体准备

**触发条件**
- 首次咨询、首次来访或临时到访：只需要选择客群标准方案；
- 客户完成首次接触，产生有效自主浏览、明确反馈、未解决问题或再次到访等可靠事实并进入追踪后：可以生成个体方案。

**系统步骤**
1. 确认当前项目、目标客户和用户权限；
2. 判断客户是否已经进入追踪并具备可靠个体事实；
3. **尚未进入追踪**：销售选择一个客群标准方案；无法判断时使用通用方案，系统不生成个体接待方案；
4. **已经进入追踪**：分开读取客户明确表达、有效现场讲解、客户自主访问和外部结果；
5. 按时间和来源整理，不把客群选择或现场展示写成客户已确认属性；
6. AI 以客群标准方案为参考，生成该客户的跟进、后续页面或复访方案；
7. 销售确认、修改或驳回个体方案；
8. 保存使用的客群方案版本、个体依据和确认版本。

**首次接触卡**只显示客群标准方案、默认内容顺序、标准提问、必讲项和风险项。**追踪客户准备卡**才显示已确认条件、历史变化、已自主了解内容、未解决问题、个体建议、候选页面及证据。

### 8.2 流程 B：已有客户现场接待
1. 销售从已有客户详情选择已发布页面并开始现场讲解；
2. 系统建立独立讲解会话，记录讲解人、客户、页面版本、展示内容、次数和可靠时长；
3. 首次接待从客群标准方案开始；复访客户可以从已确认的个体复访方案开始；
4. 销售按客户实时反馈快速跳过、追加、替换内容或调整顺序，系统保存标准/个体方案与现场实际展示的差异；
5. 涉及价格、优惠、交付、贷款或合同的信息，只引用当前有效的已发布资料；
6. 无法现场回答的问题进入未解决问题；
7. 销售结束讲解，并按实际沟通决定是否手动更新客户状态、备注或标签。

讲解记录不增加客户自主访问次数，不触发客户首次打开通知，也不能自动形成兴趣评分。

### 8.3 流程 C：临时客户现场接待
1. 销售可从页面详情开始“临时讲解”，不要求先建客户；
2. 默认使用通用客群方案；如果现场方向明确，可以切换到其他客群标准方案；
3. 讲解期间只保存现场展示事实，不创建匿名客户访问；
4. 结束后记录显示“未关联客户”；
5. 销售可以创建新客户或选择已有客户并完成关联；
6. 关联错误时，销售选择正确客户、填写理由并保留修改前后记录；
7. 误开始且不代表真实讲解时，经二次确认和填写理由后标记为无效；
8. 关联完成并产生可靠反馈后，客户进入追踪，再生成个体后续方案。

这一分支是上一版闭环图漏掉的重要入口。没有它，系统会要求销售在客户身份尚不明确时先建档，反而增加现场负担，并容易产生错误客户数据。

### 8.4 流程 D：远程咨询与首次发送
1. 客户通过电话、LINE、邮件或资料请求表达需求；
2. 销售查找或创建客户，根据本次咨询方向选择一个客群标准方案；无法判断时使用通用方案；
3. 直接使用该客群已经准备好的已发布页面和内容包，不在首次发送前为单个客户重新生成完整方案；
4. 沟通中方向发生变化时，销售可以切换客群方案或追加一个主题包；
5. 销售指定客户，取得带客户识别关系的访问地址；
6. 当前正式 PRD 下，销售在 Link 外部实际发送；目标扩展下可进入 §8.8 的 SMS 确认发送；
7. 地址复制、二维码展示或页面与客户建立关系，都不能写成“已经发送”；
8. 客户尚未真正打开前，不产生客户访问记录；
9. 客户回复或打开后产生可靠事实并进入追踪，后续才由 AI 制定个体页面和跟进方案。

### 8.5 流程 E：到访后发送资料
1. 系统读取本次使用的客群标准方案或个体复访方案、本次有效讲解记录和现场调整，列出原计划与实际展示的差异；
2. 讲解事实、现场调整与销售补充的客户反馈分开显示；
3. AI 根据差异生成结构化纪要草稿，分为已确认事实、客户表达和待确认提取；
4. 销售确认条件变化、顾虑、未解决问题及是否更新客户状态；
5. 系统只使用销售确认后的客户反馈作为后续选材条件；
6. 查找已有页面或生成新的页面工作草稿；
7. 销售检查、保存并确认发布；
8. 取得客户访问地址，并通过外部通道或 Link SMS 发送；
9. 发送的页面版本、客户、渠道和时间必须可追溯；
10. 将销售确认后的条件变化、未解决问题和后续重点写入该客户的个体跟进/复访方案，不直接覆盖项目客群标准方案。

### 8.6 流程 F：根据客户自主访问继续推荐
1. 客户打开访问地址，完成客户标识参数、访问会话或邮箱验证码识别；
2. 系统生成一次客户自主访问记录和访问内容快照；
3. 按访问数据状态排除机器人、内部测试、重复或异常记录；
4. 汇总页面、内容、次数、有效时长和 C 端已经定义的明确动作；
5. 检查客户当时看到的历史内容当前是否仍可用；
6. AI 给出带依据的询问方向和资料建议，不直接生成客户状态或确定购买意向；
7. 销售采用、修改或忽略建议；
8. 需要时选择已有页面或生成下一份页面工作草稿，再次提供访问地址；
9. 新访问形成新记录，不能改写旧页面版本、旧讲解或旧访问明细。

该流程形成 VISTA Link 真正的循环：**提供内容 → 客户自主访问 → 理解可靠行为 → 再次准备内容或接待。**

### 8.7 流程 G：购买申请至签约/未签约状态回写
1. 客户通过实际沟通确认准备购买后，购买申请、资金确认、贷款预审、重要事项说明和合同仍在外部业务中完成；
2. 系统只接收销售明确提供或权威系统回传的业务结果；
3. Link 展示客户原状态、目标状态、结果来源和更新时间；
4. 销售确认后，从当前项目未停用的状态中手动选择目标状态；
5. 完成买卖合同后可改为系统预置“签约”；未完成或客户放弃时可改为“未签约”；
6. 保存原状态、新状态、操作人、时间和外部依据引用；
7. 没有明确结果时不修改，页面访问、讲解记录和 AI 评分均不能作为签约依据。

这里的闭环是**状态回写和历史追溯**，不是在 Link 内执行购买申请、贷款或合同流程。

### 8.8 扩展流程 H：Link 原生 SMS 行动闭环

【采用，需改 PRD】SMS 是页面提供与跟进动作中的一个通道，不替代前述七类销售场景。
```mermaid
flowchart LR
    A["已确认的客户反馈或可靠访问事实"] --> B["AI准备日文SMS与客户专属页面"]
    B --> C["资料版本、同意、退订、频率和风险校验"]
    C --> D["销售查看依据、编辑并逐次确认"]
    D --> E["Link发送服务"]
    E --> F["SMS供应商"]
    F --> G["受理、送达、失败或退订回执"]
    G --> H["短链点击、客户识别和页面访问"]
    H --> I["事实写回客户时间线"]
    I --> J["进入再次推荐或接待准备"]
```

首期只支持单客户、单消息、逐次确认；必须绑定客户、页面版本、确认人、发送者和幂等键。首期不支持无限群发、未经确认的任意自动发送、高风险业务承诺，也不能把“提交给供应商”显示为“已送达”。

### 8.9 扩展流程 I：预约协调和权威结果连接

【采用，需改 PRD】预约意向不是预约成功，预约成功也不是实际到访。推荐状态机：
```mermaid
stateDiagram-v2
    [*] --> IntentDetected: 点击预约或销售确认意向
    state "预约意向" as IntentDetected
    state "建议可用时段" as SlotProposed
    state "临时时段占用" as SlotHeld
    state "等待权威确认" as PendingConfirmation
    state "预约已确认" as Confirmed
    state "预约被拒绝" as Rejected
    state "时段已过期" as Expired
    state "预约已取消" as Cancelled
    state "实际到访" as Visited
    state "未到访" as NoShow

    IntentDetected --> SlotProposed
    SlotProposed --> SlotHeld: 客户选择时段
    SlotHeld --> PendingConfirmation: 提交预约系统
    PendingConfirmation --> Confirmed: 权威系统写入成功
    PendingConfirmation --> Rejected: 冲突或不接受
    SlotHeld --> Expired: 暂占超时
    Confirmed --> Cancelled: 客户或销售取消
    Confirmed --> Visited: 人员或权威系统确认
    Confirmed --> NoShow: 人员或权威系统确认
    Rejected --> SlotProposed
    Expired --> SlotProposed
    Visited --> [*]
    NoShow --> [*]
    Cancelled --> [*]
```

Agent 可以查询可用时段、提出建议和发起暂占；只有预约/日历系统写入成功，Link 才显示“预约已确认”。确认到访后回到 §8.1 接待准备，而不是把预约流程作为业务终点。

### 8.10 治理流程：管理者复核

管理者不需要逐条审核所有 AI 摘要，只处理：
- 涉及价格、优惠、合同、交付等高风险对外内容；
- 批量发送或自动规则变更；
- 多次被纠正的 AI 结论；
- 数据来源冲突或资料过期；
- 发送失败、同步失败和权限异常；
- 临时讲解长期未关联、错误客户关联或无效记录；
- 长时间未解决的客户问题。

---

## 9\. 风险分级与人工控制

| 级别 | 示例 | 默认控制 |
|------|------|------------|
| R0 只读 | 查询项目、客户、页面、访问事实 | 直接执行，记录查询审计 |
| R1 内部草稿 | 摘要、接待卡、标签建议、纪要草稿 | 自动生成，可纠正，不写关键事实 |
| R2 普通写入 | 保存草稿、更新内部待确认字段 | 展示变更对比后由用户确认 |
| R3 对外动作 | 发布页面、发送单客户 SMS、发起预约暂占 | 逐次确认；成熟后可使用预授权规则 |
| R4 高风险动作 | 价格/优惠/合同/交付承诺、批量发送、关键策略修改 | 负责人审核；不得由普通销售自动执行 |
| R5 权威业务事实 | 已到访、已认购、已签约、金额 | 仅权威系统或有权限人员写入；AI 不得推断 |
```mermaid
flowchart LR
    A["AI结论或动作请求"] --> B["策略网关<br/>权限 / 项目 / 对象 / 版本"]
    B --> C{"风险等级"}
    C -->|R0 只读| D["直接执行并记录"]
    C -->|R1 内部草稿| E["自动生成，可纠正"]
    C -->|R2 普通写入| F["用户查看变更后确认"]
    C -->|R3 对外动作| G{"是否命中有效预授权"}
    G -->|否| H["销售逐次确认"]
    G -->|是| I["规则内执行"]
    C -->|R4 高风险| J["负责人审核"]
    C -->|R5 权威事实| K["权威系统或授权人员写入"]
    D --> L["Link业务服务"]
    E --> M["保存内部草稿"]
    F --> L
    H --> L
    I --> L
    J --> L
    K --> N["业务事实记录"]
    L --> O["结果与审计"]
    M --> O
    N --> O
```

预授权自动化必须明确：
- 适用租户、项目、角色和客户范围；
- 可使用的内容模板和版本；
- 可使用的渠道；
- 频率、时间段和金额/数量阈值；
- 有效期；
- 取消和人工接管方式；
- 每次命中规则的审计记录。

---

## 10\. 分享记录、渠道归因、ROI 与意向评分

### 10.1 分享记录是数据起点

【采用，需改 PRD】每次实际分享建立独立记录，而不是只依赖固定链接。

| 字段 | 说明 |
|------|------|
| share\_id | 随机、不可枚举的分享记录 ID |
| tenant*id / project*id | 租户与项目 |
| customer\_id | 目标客户，可为空但应标明匿名 |
| page*id / page*version | 分享页面及版本 |
| member\_id | 分享人 |
| channel / campaign\_id | LINE、SMS、邮件、二维码、活动等 |
| created\_at | 生成分享记录的时间 |
| copied*at / sent*at | 复制和实际发送是不同事件 |
| first*open*at | 首次打开时间 |
| parent*share*id | 需要时记录转发关系 |

所有参数使用内部映射或签名 Token，不在 URL 中直接暴露客户和业务敏感信息。

### 10.2 统一事件链
```mermaid
flowchart LR
    A["活动 / 渠道"] --> B["分享记录"]
    B --> C["消息发送"]
    C --> D["送达回执"]
    D --> E["打开短链"]
    E --> F["页面访问"]
    F --> G["内容行为"]
    G --> H["回复 / 预约意向"]
    H --> I["预约确认"]
    I --> J["实际到访"]
    J --> K["认购 / 签约权威结果"]
    B -. 规则版本 .-> L["归因计算"]
    K --> L
    M["活动成本"] --> N["ROI计算"]
    L --> N
    K --> N
```

每个事件至少携带租户、项目、客户或匿名身份、分享记录、内容版本、渠道、发生时间和来源系统。

### 10.3 渠道归因

第一阶段使用可解释规则：
- 首次有效触达；
- 末次有效触达；
- 指定时间窗内的线性多触点，仅在数据足够后开放。

系统保存全部原始触点和规则版本。Codex/Agent 可以选择已经批准的归因规则并解释结果，但不能临时发明口径。

### 10.4 ROI

只有同时具备以下条件，才能上线正式 ROI：
1. 渠道与活动标识稳定；
2. 广告和活动成本可获得；
3. 预约、到访、成交及金额来自权威系统；
4. 币种、税、周期、归属项目和取消/退款规则明确；
5. 归因规则版本化；
6. 缺失数据能够被识别而不是默认为零。

推荐分三层显示：
- 数据完整率；
- 漏斗转化与单位成本；
- 按批准口径计算的收入、利润或业务价值 ROI。

### 10.5 自动意向评分

实施顺序：
```mermaid
flowchart LR
    A["客观行为信号"] --> B["人员确认的客户条件"]
    B --> C["权威预约 / 到访结果"]
    C --> D["可解释规则评分"]
    D --> E["与真实结果校准"]
    E --> F{"质量是否稳定"}
    F -->|否| G["修正规则和数据"]
    G --> D
    F -->|是且确有增益| H["评估专用评分模型"]
    H --> I["显示证据、版本、衰减和纠正入口"]
```

评分输出必须包含：分值、等级、主要正负证据、规则/模型版本、置信度、衰减时间和人工纠正入口。评分不能成为拒绝服务、改变价格或自动作出重大业务决定的唯一依据。

---

## 11\. 核心业务对象

### 11.1 正式 PRD 对象
- 租户、项目、成员、角色、权限；
- 客户、素材、页面、页面版本、Widget；
- 固定链接、客户专属访问地址、访问会话；
- 行为事件、客户追踪、营销统计；
- AI 会话、任务、草稿、确认与审计。

### 11.2 建议新增对象

| 对象 | 用途 | 状态 |
|------|------|------|
| reception\_playbook | 项目级客群标准方案；保存客群定义、默认内容包、标准提问、必讲项、风险项和版本 | 【采用，需改 PRD】 |
| content\_package | 按项目概况、交通、户型、眺望日照、公共设施、价格费用等主题组织当前有效内容 | 【采用，需改 PRD】 |
| customer\_condition | 客户条件、来源、确认和历史 | 【采用，需改 PRD】 |
| visit\_session | 区分第几次接待和现场模式 | 【采用，需改 PRD】 |
| first*contact*plan | 首次咨询/首次接待所选择的客群标准方案及版本；不是客户已确认属性 | 【采用，需改 PRD】 |
| customer*followup*plan | 客户进入追踪后，根据明确反馈、有效行为和历史生成的个体跟进、页面或复访方案 | 【采用，需改 PRD】 |
| visit\_preparation | 追踪客户的复访准备快照、个体依据、AI 建议和销售确认版本 | 依据正式 AI 能力细化 |
| visit\_adjustment | 保存现场相对客群标准方案或个体复访方案的增加、跳过、替换及理由 | 【采用，需改 PRD】 |
| visit\_summary | 接待后纪要草稿、原方案与实际接待差异、人工确认版本 | 依据正式 AI 能力细化 |
| unresolved\_question | 未解决问题、负责人、状态和期限 | 【采用，需改 PRD】 |
| share\_record | 每次分享、渠道、活动和客户关系 | 【采用，需改 PRD】 |
| consent\_record | 通信同意、退订、渠道和有效期 | 【采用，需改 PRD】 |
| message / message\_version | SMS 草稿、确认版本和实际发送版本 | 【采用，需改 PRD】 |
| message\_delivery | 供应商状态、送达、失败和重试 | 【采用，需改 PRD】 |
| appointment\_reference | Link 与预约权威系统之间的映射 | 【采用，需改 PRD】 |
| business*outcome*reference | 到访/认购/签约等必要结果引用；只保存必要结果 | 【采用，需改 PRD】 |
| ai\_conclusion | 结论、证据、版本、置信度和失效 | 【正式 PRD】 |
| action\_request | Agent 提出的结构化动作 | 【正式 PRD】 |
| approval\_decision | 确认、修改、驳回、审核 | 【正式 PRD】 |
| attribution\_result | 规则、窗口、触点和分配结果；后置建设 | 【采用，需改 PRD】 |
| roi\_result | 公式、数据范围、币种和结果；后置建设 | 【采用，需改 PRD】 |
| intent\_score | 特征、版本、解释、衰减和纠正；后置建设 | 【采用，需改 PRD】 |

---

## 12\. Agent 工具设计

### 12.1 工具原则
- 工具只表达业务动作，不提供“执行任意 SQL”或“调用任意 URL”；
- 所有对象 ID 由服务端再次按租户、项目和权限校验；
- 写入工具要求版本号或幂等键；
- 对外动作保存确认人、确认版本和实际执行结果；
- 关键事实必须调用权威服务，不让模型生成。

### 12.2 当前 PRD 内工具示例
```text
get_current_context()
search_customers(project_id, filters)
get_customer_detail(customer_id)
get_customer_activity(customer_id, source_type)
search_assets(project_id, query)
get_page(page_id, version)
compose_page_draft(customer_id, asset_ids)
save_page_draft(draft_id, expected_version)
publish_page(page_id, expected_version)
generate_visit_preparation(customer_id)
generate_visit_summary(visit_session_id)
get_dashboard_metrics(project_id, metric_definition_version)
```

### 12.3 扩展工具示例
```text
list_reception_playbooks(project_id, customer_segment)
select_first_contact_playbook(customer_id_optional, playbook_id, expected_playbook_version)
create_customer_followup_plan(customer_id, evidence_ids, expected_version)
create_revisit_preparation(customer_id, followup_plan_id, expected_version)
record_onsite_adjustment(visit_session_id, changes, reason, idempotency_key)
finalize_visit_summary(visit_session_id, confirmed_changes, expected_version)
create_share_record(customer_id, page_version, channel, campaign_id)
create_sms_draft(customer_id, template_id, page_version)
send_approved_message(action_id, confirmation_token)
query_available_slots(project_id, date_range)
hold_appointment_slot(customer_id, slot_id, idempotency_key)
confirm_appointment(hold_id, confirmation_token)
calculate_attribution(project_id, window, approved_model_version)
calculate_roi(project_id, period, metric_definition_version)
refresh_intent_score(customer_id, scoring_version)
```

Agent 只负责决定“建议调用哪个工具并准备参数”；Link 的策略网关决定“当前用户是否可以调用、是否需要确认、是否满足规则”；业务服务负责实际写入和外部调用。
```mermaid
sequenceDiagram
    participant U as 销售用户
    participant UI as 浏览器AI面板
    participant A as Agent运行层
    participant P as Link策略网关
    participant S as Link业务服务
    participant X as 外部系统

    U->>UI: 提出任务
    UI->>A: 发送当前项目和对象上下文
    A->>A: 生成结构化工具调用候选
    A->>P: action_request
    P->>P: 校验权限、版本、风险和幂等
    alt 需要人工确认
        P-->>UI: 返回确认卡和变更对比
        UI-->>U: 展示依据与影响
        U->>UI: 确认、修改或驳回
        UI->>P: approval_decision
    else 命中允许规则
        P->>P: 记录预授权命中依据
    end
    P->>S: 执行强类型业务动作
    S->>X: 发送、发布或预约调用
    X-->>S: 权威执行结果
    S-->>A: 工具结果
    A-->>UI: 解释结果和下一步
    UI-->>U: 展示完成状态与审计入口
```

---

## 13\. 浏览器、多租户与服务端架构

### 13.1 总体结构
```mermaid
flowchart TB
    UI["浏览器中的 Link 与 AI 面板"] --> GW["Agent Gateway"]
    GW --> CTX["上下文构建服务"]
    GW --> POLICY["工具与策略网关"]
    GW --> TASK["任务与会话服务"]
    TASK --> QUEUE["任务队列"]
    QUEUE --> WORKER["Agent Workers"]
    WORKER --> MODEL["模型网关 / OpenAI / 其他模型"]
    WORKER --> POLICY
    POLICY --> LINK["Link 业务服务"]
    LINK --> DB["租户与项目数据"]
    LINK --> CONNECT["SMS / LINE / 日历 / CRM / 预约连接器"]
    GW --> AUDIT["AI与业务审计"]
```

### 13.2 浏览器负责
- 呈现当前上下文；
- 收集用户输入和附件；
- 展示流式进度、依据、草稿、差异和确认卡；
- 允许取消、重试、修改和人工接管；
- 浏览器关闭后能够恢复任务状态。

### 13.3 服务端负责
- 身份认证、租户/项目/对象权限；
- 上下文最小化和敏感字段脱敏；
- 模型选择、提示和知识检索；
- 工具参数校验、风险分级和确认；
- 长任务、重试、幂等和检查点；
- 外部系统调用、结果回写和审计；
- 配额、成本、限流和公平调度。

### 13.4 多租户强制规则

每次 AI 请求和工具调用必须包含并由服务端验证：
```text
tenant_id
project_id
user_id
role_ids
object_type
object_id
permission_snapshot_version
request_id
```

数据库查询不得只依赖模型返回的 ID。所有查询都要附加当前租户与项目范围；项目切换后，旧对话不能继续无提示地使用旧项目上下文。

### 13.5 任务模型

浏览器会话不等于任务。建议状态：
```mermaid
stateDiagram-v2
    [*] --> Created
    state "已创建" as Created
    state "排队中" as Queued
    state "运行中" as Running
    state "等待用户补充" as WaitingUser
    state "等待审批" as WaitingApproval
    state "执行业务动作" as Executing
    state "已完成" as Completed
    state "失败" as Failed
    state "已取消" as Cancelled
    state "已过期" as Expired

    Created --> Queued
    Queued --> Running
    Running --> WaitingUser: 缺少必要信息
    Running --> WaitingApproval: 需要确认或审核
    WaitingUser --> Queued: 用户补充后继续
    WaitingApproval --> Executing: 通过
    WaitingApproval --> Cancelled: 驳回或取消
    Running --> Executing: 无需审批
    Executing --> Completed
    Running --> Failed
    Executing --> Failed
    Created --> Cancelled
    Queued --> Expired: 超过有效期
    Completed --> [*]
    Failed --> [*]
    Cancelled --> [*]
    Expired --> [*]
```

长任务保存检查点，浏览器刷新或关闭后可以重新连接。写入动作不能因为前端重复提交而重复执行。

---

## 14\. 模型与供应商方案

### 14.1 模型中立

业务对象、工具、权限、确认和审计由 Link 定义，不绑定某一家模型。OpenAI、DeepSeek 或未来其他模型只处于推理与编排层。

### 14.2 路由原则
```mermaid
flowchart TD
    A["收到AI任务"] --> B{"确定规则能完成吗"}
    B -->|能| C["使用规则或数据库查询"]
    B -->|不能| D{"任务类型"}
    D -->|分类 / 提取 / 整理| E["低成本模型"]
    D -->|复杂摘要 / 比较 / 草稿| F["主模型"]
    D -->|高敏感或禁止外发| G["指定区域 / 私有模型 / 人工"]
    E --> H{"输出与工具校验通过吗"}
    F --> H
    G --> H
    H -->|通过| I["进入证据、确认和业务流程"]
    H -->|模型失败| J["备用模型"]
    H -->|数据或规则失败| K["安全降级或人工处理"]
    J --> H
```

### 14.3 API Key 管理
- Key 只保存在服务端密钥系统；
- 测试与生产分离；
- 按租户、项目、模型和功能设置额度；
- 日志不出现完整 Key、手机号和客户敏感信息；
- 支持平台统一 Key、企业自带 Key 和企业专属部署；
- 普通销售界面不出现“选择模型”或“填写 API Key”。

### 14.4 Codex/DeepSeek Harness 的正确关系

可以参考 Codex 或 DeepSeek Harness 的“理解上下文—制定步骤—调用工具—返回结果”模式，但 VISTA Link 需要构建自己的：
- 房地产业务对象；
- 租户和项目权限；
- 页面、访问、客户、发送和预约工具；
- 确认与审计；
- 浏览器端任务体验。

不能把通用编码智能体直接暴露给企业客户，更不能让其直接接触操作系统或数据库。

---

## 15\. OpenAI 官方文档与 Link 方案对应章节
> 核对日期：2026-08-22。OpenAI API、模型、价格、限额和数据政策会更新；开发启动和上线前应再次核对官方文档。采用原则：OpenAI 提供模型、推理、工具调用和托管工具能力；VISTA Link 仍负责租户、项目、权限、业务状态、人工确认和审计。   

### 15.1 OpenAI 文档总映射

| OpenAI 官方文档及具体章节 | 官方能力 | 对应本文章节 | Link 中的采用方式 |
|----------------------------------|------------|------------------|-----------------------|
| [Create a model response / Responses API](https://developers.openai.com/api/reference/cli/resources/responses/methods/create) | 文本、图片、文件输入；会话；工具；流式和后台响应 | §5 产品形态、§12 工具、§13 Agent 架构 | 作为 OpenAI 供应商适配器的核心推理接口 |
| [Function calling — How it works](https://developers.openai.com/api/docs/guides/function-calling#how-it-works) | 模型生成函数调用名称和参数，由应用执行函数并回传结果 | §9 风险分级、§12 Agent 工具设计 | 实现强类型 Link 业务工具；模型不直接操作数据库或供应商 |
| [Structured model outputs](https://developers.openai.com/api/docs/guides/structured-outputs) | 使模型输出符合给定 JSON Schema | §7 证据模型、§11 业务对象、§12 工具公共结构 | 约束 `ai_conclusion`、`action_request` 等输出；服务端仍需二次校验 |
| [File search — How to use](https://developers.openai.com/api/docs/guides/tools-file-search#how-to-use) | 从上传文件和向量库中进行语义与关键词检索，并返回文件引用 | §6 内容库、§7 依据、§13 上下文 | 可用于检索项目资料；必须按租户、项目、版本和有效期过滤 |
| [File search — Metadata filtering](https://developers.openai.com/api/docs/guides/tools-file-search#metadata-filtering) | 按文件元数据限制检索结果 | §6.4 内容与页面库、§13.4 多租户规则 | 元数据至少包含租户、项目、资料类型、版本、状态和生效期 |
| [MCP and Connectors — Approvals](https://developers.openai.com/api/docs/guides/tools-connectors-mcp#approvals) | 通过连接器或远程 MCP 访问外部系统，并支持调用前批准 | §9 人工控制、§12.3 扩展工具、§17 外部系统 | 用于外部 Agent 或标准连接；Link 自身权限和确认网关不能省略 |
| [MCP and Connectors — Risks and safety](https://developers.openai.com/api/docs/guides/tools-connectors-mcp#risks-and-safety) | 说明远程 MCP 可能接触和传出敏感上下文 | §13 多租户、§19 数据安全 | 只连接受信任 MCP；最小化上下文；记录实际外发字段 |
| [Background mode](https://developers.openai.com/api/docs/guides/background) | 异步执行长时间响应并轮询状态 | §5.4 AI 任务中心、§13.5 任务模型 | 可承载长摘要或大批资料检查；Link 任务表仍是业务状态来源 |
| [Model guidance](https://developers.openai.com/api/docs/guides/latest-model) | 模型选择、推理强度、工具调用和评测建议 | §14 模型路由、§18 容量、§22 验收 | 不把当前模型名称写死在业务代码；通过评测和路由配置选择 |
| [Data controls in the OpenAI platform](https://developers.openai.com/api/docs/guides/your-data) | API 数据使用、应用状态、监测日志和保留控制 | §19 数据与隐私 | 按使用的端点和功能逐项确认数据保留；企业合同与法务评审优先 |
| [Rate limits](https://developers.openai.com/api/docs/guides/rate-limits) / [Cost optimization](https://developers.openai.com/api/docs/guides/cost-optimization) | 供应商限额、吞吐和成本优化 | §18 容量、§22 系统验收 | 建立租户级限流、使用量记录、模型路由和预算预警 |
| [Safety best practices](https://developers.openai.com/api/docs/guides/safety-best-practices) | 上线前安全设计、测试和人工控制建议 | §9 风险分级、§19 安全 | 高风险对外内容人工审核，输入输出限制并开展对抗测试 |

### 15.2 Responses API 在 Link 中的责任

OpenAI Responses API 可以处理输入、生成响应、调用自定义工具或内置工具，并支持多轮状态、流式响应和后台执行。它适合作为 Link 的模型运行接口，但不应成为 Link 的业务数据库。

推荐调用关系：
```text
浏览器 AI 面板
→ Link Agent Gateway
→ 构建最小项目上下文
→ OpenAI Responses API
→ 返回文本、结构化结果或工具调用请求
→ Link 策略网关检查
→ 人员确认或预授权规则
→ Link 业务服务执行
→ 执行结果回传模型并写入 Link 审计
```

Link 必须自行保存：
- `agent_task_id` 和任务状态；
- 租户、项目、用户和对象权限快照；
- 使用的资料与版本；
- 模型返回的结构化草稿；
- 用户确认、修改或驳回；
- 实际业务执行结果；
- 外部供应商响应和异常。

OpenAI 的 `response_id`、`conversation` 或 `previous_response_id` 仅作为模型调用引用，不能替代上述业务记录。

### 15.3 Function calling 对应 Link 的受控执行

OpenAI 官方文档明确的工作方式是：模型返回工具调用，应用程序执行实际函数，再把结果返回给模型。由此可直接得出 Link 的实现边界：

| 环节 | OpenAI/模型负责 | Link 负责 |
|------|-------------------|-----------|
| 选择动作 | 根据上下文建议调用某个允许的工具 | 限定本次可见工具集合 |
| 生成参数 | 按工具 Schema 生成候选参数 | 验证类型、租户、项目、对象、版本和业务规则 |
| 执行动作 | 不直接执行 | Link 业务服务或连接器执行 |
| 处理结果 | 读取工具结果并继续生成解释或下一步 | 判断结果是否为权威事实并持久化 |
| 失败重试 | 可以提出重试建议 | 决定是否可重试、是否会重复写入以及如何补偿 |

因此，以下做法不允许：
- 把数据库连接、任意 SQL 或通用 HTTP 请求暴露成模型工具；
- 仅因为参数符合 JSON Schema 就直接执行；
- 由模型自行构造租户、项目或用户权限；
- 把工具调用请求误写成已发送、已发布或预约已确认；
- 对有副作用的工具进行无幂等保护的自动重试。

### 15.4 Structured Outputs 对应业务数据结构

OpenAI Structured Outputs 用于约束模型输出符合 JSON Schema，适合以下对象：
- 客户条件提取结果；
- 接待准备卡；
- 接待纪要草稿；
- AI 结论与证据引用；
- SMS 草稿风险检查；
- 工具调用前的 `action_request`；
- 归因或评分的解释结构。

示意结构：
```json
{
  "conclusion_type": "visit_preparation",
  "customer_id": "cus_internal_id",
  "facts": [],
  "customer_statements": [],
  "inferences": [],
  "evidence_ids": [],
  "source_versions": [],
  "needs_human_confirmation": true
}
```

结构化输出只能降低格式错误，不能证明内容真实。Link 仍要验证：
1. `customer_id` 是否属于当前项目；
2. `evidence_ids` 是否存在且用户有权查看；
3. 资料版本是否有效；
4. 枚举和状态转换是否符合业务规则；
5. 是否涉及对外发送或高风险承诺；
6. 是否需要人工确认。

### 15.5 File search 对应项目知识库

OpenAI File search 可以从向量库搜索已上传文件并生成带文件引用的回答。若采用该托管工具，建议每次检索至少限制：
```text
tenant_id
project_id
document_type
document_status = published
effective_from <= current_time
effective_to > current_time 或为空
language = ja / zh / en
```

资料入库流程：
```text
资料上传
→ 病毒与格式检查
→ 权限和项目归属
→ 生成资料版本
→ 审核并发布
→ 写入向量库与元数据
→ AI检索
→ 返回文件引用
→ 用户可打开 Link 中的原始资料版本
```

若企业不允许文件上传到外部托管向量库，则使用 Link 自建检索或企业专属向量库；模型只接收已经过滤后的必要片段。

### 15.6 MCP 对应外部 Agent 和系统连接

OpenAI MCP 文档说明远程 MCP 和连接器可以赋予模型访问外部服务的能力，并提供调用审批机制。VISTA Link 可以把自己的有限业务能力暴露为 MCP 工具，但建议分两种模式：

| 模式 | 场景 | 推荐控制 |
|------|------|------------|
| Link 调用外部 MCP | 获取日历、CRM 或企业资料 | 受信任服务器白名单、OAuth、最小字段、调用前批准 |
| 外部 Agent 调用 Link MCP | Codex 或企业 Agent 读取 Link、发起草稿或动作 | Link 认证、用户授权、项目范围、工具白名单、二次确认和审计 |

OpenAI 的 MCP approval 是额外防线，不替代 Link 自己的权限和业务确认。任何 `send`、`publish`、`hold_slot`、`confirm` 类型工具仍执行 §9 的风险分级。

### 15.7 Background mode 与浏览器任务中心

后台模式适用于可能持续数分钟的模型响应。Link 中可用于：
- 大项目资料一致性检查；
- 多客户接待准备的批量预生成；
- 历史页面版本比较；
- 大量行为记录摘要；
- 非实时的质量评测。

但浏览器任务中心不能直接依赖一次 HTTP 连接：
1. Link 先建立 `agent_task`；
2. 调用 OpenAI 后保存供应商响应 ID；
3. Worker 轮询或接收回调；
4. 将供应商状态映射为 Link 状态；
5. 浏览器通过 SSE/WebSocket 读取 Link 状态；
6. 任务完成后仍由 Link 保存业务草稿、确认和审计。

官方后台模式存在特定的数据暂存和保留行为，使用前需要结合企业数据要求审查；高敏感租户可以改用前台响应、专属策略或其他部署方式。

### 15.8 Codex 与 VISTA Link 的关系

Codex 的价值是提供一种可参考的 Agent 交互模式：理解上下文、拆解任务、调用工具、展示过程、等待批准、继续执行。VISTA Link 不应复制 Codex 的代码编辑、Shell 或本地文件系统能力。
```text
参考 Codex 的：任务体验、工具编排、过程可见、批准和恢复
不复制 Codex 的：代码工作区、通用 Shell、任意文件修改、开发者权限模型
Link 自己建设的：客户/页面/接待/SMS/预约对象、项目权限和业务审计
```

结论：面向企业客户的产品可以“像 Codex 一样工作”，但底层应以 Responses API、Function calling、MCP 和 Link 自己的业务服务组合，而不是把 Codex 客户端直接嵌入 Link。

### 15.9 数据、限流、成本和安全文档如何落地

OpenAI 官方数据控制文档说明 API 数据的使用与保留会受到所用功能和账户配置影响；因此不能只写一句“使用 OpenAI API”，而应在技术设计中建立逐功能清单：

| 功能 | 发送数据 | 是否保存供应商对象 | 保留/删除方式 | Link 替代方案 |
|------|------------|---------------------------|-------------------|-----------------|
| 普通 Responses 请求 | 最小任务上下文 | 按实际 `store` 和企业策略 | 以官方账户和端点规则为准 | 前台无状态请求或其他供应商 |
| Background mode | 长任务上下文 | 为异步执行存在必要暂存 | 按官方后台模式规则评审 | Link Worker 拆分为短请求 |
| File search | 上传文件和向量索引 | 存在文件与向量库对象 | 项目停用时执行删除流程 | Link 自建/企业向量库 |
| MCP/Connector | 发给 OpenAI 及目标服务的必要上下文 | 同时受 MCP 服务方规则影响 | 两端分别确认 | Link 直连接口 |

限流与成本方面，Link 的租户额度应低于供应商账户上限，并记录每次任务的输入、输出、缓存、工具调用和重试成本。供应商返回 429、超时或配额不足时，应进入备用模型、延迟队列或人工模式，而不是让浏览器无限重试。

安全方面，对外消息、价格政策、合同解释、批量操作和业务事实继续遵守 §9 的人工控制。稳定的最终用户标识应使用不可逆或隐私保护的内部映射，不直接发送姓名、邮箱或手机号作为供应商用户标识。

---

## 16\. DeepSeek API、DeepSeek Harness 官方文档与 Link 方案对应章节
> 名称说明：正确英文名称为 **DeepSeek**；本文保留用户常用的“DeepSeek Harness”表述。核对日期：2026-08-22。DeepSeek Harness 当前官方定位为 developer preview，架构和接口仍可能发生不兼容变化。   

### 16.1 DeepSeek 文档总映射

| DeepSeek 官方文档及具体章节 | 官方能力 | 对应本文章节 | Link 中的采用方式 |
|------------------------------------|------------|------------------|-----------------------|
| [Your First API Call](https://api-docs.deepseek.com/) | OpenAI/Anthropic 兼容形式的模型 API 接入 | §14 模型中立、§16.2 供应商适配 | 作为模型供应商之一，通过 Provider Adapter 接入 |
| [Tool Calls](https://api-docs.deepseek.com/guides/tool_calls) | 模型生成外部工具调用；应用负责执行；提供 strict 模式说明 | §9 风险、§12 工具设计 | 使用同一 Link 业务工具定义，但进行 DeepSeek 兼容测试 |
| [JSON Output — Notice](https://api-docs.deepseek.com/guides/json_mode/#notice) | 输出有效 JSON 的配置与限制 | §7、§11、§16.4 | 用于结构化草稿；不能等同于完整业务校验 |
| [Thinking Mode — Tool Calls](https://api-docs.deepseek.com/guides/thinking_mode#tool-calls) | 思考模式中的多轮工具调用及上下文传递要求 | §13.5 任务、§16.5 Adapter 状态 | 适配器保留供应商要求的消息字段，不在前端展示原始推理 |
| [Multi-round Conversation](https://api-docs.deepseek.com/guides/multi_round_chat) | Chat API 本身无状态，调用方传递历史消息 | §13.5 任务模型 | Link 自己保存会话和上下文，按最小必要原则重建请求 |
| [Context Caching](https://api-docs.deepseek.com/guides/kv_cache/) | 对重复前缀进行缓存并返回命中统计 | §14 模型路由、§18 容量成本 | 通过稳定系统提示和资料前缀改善成本，但不依赖必然命中 |
| [Rate Limit & Isolation](https://api-docs.deepseek.com/quick_start/rate_limit/) | 账户并发、429 和 `user_id` 隔离参数 | §18 多用户容量 | 用于供应商限流适配；不能替代 Link 租户隔离 |
| [DeepSeek Harness developer preview](https://www.deepseek.com/harness/) | 插件化 Agent Harness、可追溯运行、Web UI 和多种运行模式 | §13 Agent 架构、§16.6 Harness 使用方式 | 作为运行时研究、企业专属部署候选或架构参考 |
| [DeepSeek Harness Architecture](https://github.com/deepseek-ai/deepseek-harness/blob/master/docs/architecture.md) | Cordis 插件系统，模型、工具、会话和 Agent Loop 可替换 | §13、§14 | 参考其插件化 Provider/Tool/Session 设计，不直接继承业务权限 |
| [Use the Web UI](https://deepseek-harness.github.io/deepseek-harness/en/guide/quickstart) | 浏览器界面、工作区、任务和操作批准 | §5 浏览器产品形态 | 证明浏览器使用方式可行；Link 仍需自己的非技术业务界面 |
| [Python SDK](https://github.com/deepseek-ai/deepseek-harness/blob/master/python/sdk/README.md) | 通过 SDK 驱动 Harness 运行时和会话 | §16.6、§18 部署 | 适合原型、内部工具或隔离运行时评估，不作为首期必选依赖 |
| [Data Processing Statement](https://www.deepseek.com/harness/data-processing/) | 本地默认处理范围，以及外部模型、MCP、插件可能产生的数据外发 | §19 数据与隐私 | 建立逐工具数据流清单，不能只依据“本地优先”判断合规 |
| [Safe Use Policy](https://www.deepseek.com/harness/en/privacy/) | 本地执行、联网和不可信数据可能带来的安全风险；建议隔离环境 | §19 安全、§16.7 Harness 边界 | 若运行 Harness，必须使用容器/虚拟机、最小权限和网络白名单 |

### 16.2 DeepSeek API 作为模型供应商

DeepSeek API 可以通过兼容接口接入现有 SDK，但“接口形式兼容”不代表“功能和行为完全一致”。Link 的 Provider Adapter 需要统一以下内部契约：
```text
generate_text()
generate_structured_output()
request_tool_call()
continue_with_tool_result()
stream_events()
cancel_or_timeout()
report_usage()
normalize_error()
```

每次增加或升级 DeepSeek 模型时，至少验证：
- 日文客户沟通草稿质量；
- JSON/Schema 兼容性；
- 工具名称和参数遵循程度；
- 多轮工具调用；
- 流式事件格式；
- 超时、429、服务过载和重试行为；
- 上下文长度和截断；
- 缓存命中统计；
- 内容安全和敏感信息处理；
- 供应商数据政策。

### 16.3 Tool Calls 对应 Link 工具网关

DeepSeek 官方 Tool Calls 文档同样说明：模型输出调用请求，具体函数由使用方提供和执行。因此 OpenAI 与 DeepSeek 可以共享 §12 中的业务工具定义，但不能直接共享所有供应商请求体。

推荐结构：
```text
Link 标准工具 Schema
        ↓
Provider Adapter 转换
        ├─ OpenAI Function tool
        └─ DeepSeek Tool Calls
        ↓
供应商返回工具调用候选
        ↓
统一解析为 Link action_request
        ↓
Link 权限、风险、确认和幂等检查
        ↓
Link 业务服务执行
```

DeepSeek strict 模式可减少工具参数格式错误，但其使用范围和支持的 JSON Schema 特性需要单独验证。无论是否 strict，Link 都必须执行服务端权限和业务校验。

### 16.4 JSON Output 与 OpenAI Structured Outputs 的差异

两类能力不能简单视为同一等级：

| 项目 | OpenAI Structured Outputs | DeepSeek JSON Output | Link 统一处理 |
|------|-------------------------|--------------------|-----------------|
| 主要目标 | 按给定 JSON Schema 输出 | 输出有效 JSON 字符串 | 转换为内部 DTO |
| 约束强度 | 以官方支持的 JSON Schema 为准 | 官方说明需要提示中写明 JSON 和示例，并提示可能出现空内容 | 必须做字段、枚举、对象权限和事实验证 |
| 工具参数 | Function calling 可定义严格工具结构 | Tool Calls 有 strict Beta 模式 | 生产前做供应商契约测试 |
| 失败处理 | 解析失败、拒答、未完成分别处理 | 空内容、截断、JSON 解析失败分别处理 | 不允许失败结果进入业务写入 |

因此，Link 对外只暴露统一的 `ai_conclusion` 和 `action_request`，供应商差异封装在 Adapter 内部。

### 16.5 思考模式和多轮会话

DeepSeek 官方文档说明 Chat API 的多轮上下文由调用方管理；思考模式进行工具调用时，还存在需要正确传递相应消息字段的供应商要求。

Link 的处理方式：
1. Agent Task Service 保存标准化对话和工具事件；
2. DeepSeek Adapter 保存继续调用所需的供应商字段；
3. 上下文构建器决定哪些历史事实仍有效；
4. 对长期会话进行摘要或压缩，而不是无限发送全部历史；
5. 原始推理内容不作为销售端解释，也不当作业务审计依据；
6. 给用户展示的是证据、工具调用、输入资料版本和最终结论。

这可以避免把供应商内部推理与 Link 所要求的“可解释业务证据”混为一谈。

### 16.6 DeepSeek Harness 可以怎么使用

DeepSeek Harness 官方将其描述为本地优先、可扩展的 Agent 开发/运行环境，能力通过插件组合，并以追加式会话日志支持追踪、恢复、分叉、搜索和回放。

对 Link 有价值的参考包括：
- 模型、工具、会话、存储、Agent Loop 和 UI 可插拔；
- 单次运行过程可追踪；
- 支持 Web UI 和程序化 SDK；
- 能通过配置组合不同运行模式；
- 可以把供应商运行时部署在隔离环境。

推荐采用方式：

| 方案 | 建议 | 原因 |
|------|------|------|
| 直接把 Harness Web UI 给销售使用 | 不采用 | 面向开发者和代码工作区，业务语言、权限和交互不符合销售场景 |
| 把 Harness 作为 Link 的唯一后端 | 暂不采用 | 当前为 developer preview，且 Link 仍需完整业务层和多租户治理 |
| 用 Harness 做内部原型和工具编排验证 | 可以 | 快速验证 Agent Loop、插件和可追溯体验 |
| 企业专属隔离运行时 | 条件采用 | 客户要求本地/专属运行且完成安全、兼容和运维评估后 |
| 借鉴其插件架构 | 采用 | 与 Link 模型中立、工具中立和会话可追溯目标一致 |

### 16.7 DeepSeek Harness 的安全和数据边界

“本地优先”不等于“所有数据永不离开环境”。DeepSeek Harness 数据处理说明明确提示：当调用外部模型、网络工具、MCP 或插件时，数据可能由相应服务方处理。因此需要建立以下清单：

| 数据流 | 必须记录 |
|---------|------------|
| Harness → 模型 API | 发送的客户字段、资料片段、模型供应商和区域 |
| Harness → MCP/插件 | 工具名称、参数、目标服务器、授权用户和返回结果 |
| Harness 本地存储 | 会话、工具日志、附件、文件路径、凭据和保存期限 |
| 遥测/诊断 | 是否开启、字段范围、脱敏方式和接收地址 |

若 Harness 获得 Shell 或文件编辑能力，必须在专用容器或虚拟机中运行，并实施：
- 非 root 用户；
- 只挂载明确工作目录；
- 禁止访问 Link 生产数据库；
- 外连网络白名单；
- 临时凭据和密钥代理；
- CPU、内存、运行时间和进程数限制；
- 会话结束后的工作区清理；
- 工具调用与文件变化审计。

对于 VISTA Link 的常规销售 Agent，推荐完全不暴露 Shell 和通用文件编辑工具，只暴露 §12 的业务工具。

### 16.8 OpenAI 与 DeepSeek 的统一选择原则
```mermaid
flowchart LR
    A["Link浏览器AI"] --> B["Agent Gateway"]
    B --> C["统一上下文与任务"]
    C --> D["Provider Adapter"]
    D --> E["OpenAI Responses API"]
    D --> F["DeepSeek API"]
    D -. 企业专属候选 .-> G["隔离的DeepSeek Harness运行时"]
    E --> H["标准化文本 / 结构化结果 / 工具调用"]
    F --> H
    G --> H
    H --> I["Link策略与权限网关"]
    I --> J["Link强类型业务工具"]
    J --> K["客户 / 页面 / SMS / 预约 / 归因"]
    K --> L["统一结果与审计"]
    L --> A
```

| 维度 | OpenAI 路径 | DeepSeek 路径 | Link 决策原则 |
|------|-------------|---------------|-----------------|
| 核心 API | Responses API | Chat/兼容 API；按当期能力评估 | 通过 Provider Adapter 隔离 |
| 工具调用 | Function calling、MCP | Tool Calls；Harness 插件工具 | 统一转成 Link action\_request |
| 结构化输出 | JSON Schema Structured Outputs | JSON Output、strict Tool Calls | 统一 DTO 和服务端校验 |
| 长任务 | Background mode | Link 自己的队列/Worker；Harness 会话 | Link 任务状态始终为主 |
| 知识检索 | File search 或外部检索 | Link 自建检索、Harness 插件或兼容能力 | 先按租户/项目过滤再给模型 |
| 浏览器体验 | Link 自建 UI | Harness 有开发者 Web UI | 销售端统一使用 Link UI |
| 本地/专属运行 | 取决于模型和企业方案 | Harness 提供本地优先运行时参考 | 按客户合规和运维成本选择 |
| 切换方式 | OpenAI Adapter | DeepSeek Adapter | 业务对象、工具和审计不随供应商变化 |

模型供应商的最终选择不能只看单次价格或演示效果。应使用同一批日文销售任务、相同证据和相同工具 Schema，对质量、延迟、成本、格式遵循、工具成功率和数据政策进行评测。

---

## 17\. 外部系统集成

### 17.1 统一集成层

所有 CRM、预约、日历、广告和交易系统通过统一接口层连接：
```mermaid
flowchart LR
    subgraph EXT["外部权威系统"]
        A["CRM"]
        B["预约 / 日历"]
        C["SMS / LINE / 邮件"]
        D["广告 / 活动"]
        E["交易 / 合同 / 财务"]
    end

    subgraph HUB["Link统一集成层"]
        F["API与Webhook"]
        G["身份和字段映射"]
        H["幂等、重试和冲突规则"]
        I["同步日志与告警"]
    end

    subgraph LINK["VISTA Link业务层"]
        J["客户与内容"]
        K["访问与分享"]
        L["AI任务与行动"]
        M["结果、归因与审计"]
    end

    A <--> F
    B <--> F
    C <--> F
    D <--> F
    E <--> F
    F --> G
    G --> H
    H --> I
    H <--> J
    H <--> K
    H <--> L
    H <--> M
```
- 标准 API；
- Webhook；
- 外部 ID 与 Link ID 映射；
- 字段映射；
- 幂等和重复事件处理；
- 失败重试；
- 冲突规则；
- 同步日志和告警；
- 权限和个人信息最小化。

### 17.2 推荐接入顺序
1. CSV 导入导出和人工兜底；
2. SMS 供应商；
3. 预约/日历系统；
4. 主要 CRM；
5. 广告与活动数据；
6. 交易系统必要结果；
7. LINE/邮件等更多触达渠道。

### 17.3 主数据归属

| 数据 | 推荐权威来源 |
|------|------------------|
| 项目内容、页面和访问行为 | VISTA Link |
| 客户基本资料与负责人 | 项目确定 Link 或 CRM 中的一方为主 |
| 通信同意与退订 | 实际发送平台与 Link 同步，取更严格状态 |
| 可预约时段和预约确认 | 预约/日历系统 |
| 实际到访 | 预约系统、门店系统或有权限人员 |
| 认购、签约、金额 | CRM/交易/合同系统 |
| 活动成本 | 广告或财务系统 |
| 归因、内容效果和 AI 工作记录 | VISTA Link |

---

## 18\. 服务器要求与多 B 端用户方案

### 18.1 推荐部署方式

使用模型 API 时，Link 服务器不运行大模型，主要承担鉴权、上下文、任务队列、工具调用、数据库和连接器。服务器要求远低于自建大模型，不需要在初期配置 GPU。

### 18.2 起步配置建议

| 阶段 | 参考规模 | 推荐起步资源 | 说明 |
|------|------------|------------------|------|
| 企业试点 | 1—3 个项目、约 50 名用户 | 2 个应用实例，各 2—4 vCPU/4—8 GB；托管 PostgreSQL；Redis；对象存储 | 保证高可用和可回滚 |
| 商业初期 | 10—30 个租户、数百用户 | 3—6 个无状态应用实例；独立 Worker；托管数据库高可用；队列与集中日志 | 按任务类型和租户限流 |
| 规模化 | 数千月活、数百并发任务 | 应用、Agent Worker、连接器 Worker 分池；数据库读副本/分区；自动扩缩容 | 容量以并发任务而非注册用户数估算 |
| 企业专属 | 单一大型客户 | 专属命名空间、数据库或密钥，必要时专属 Worker | 满足隔离和合规要求 |

实际容量必须通过压测验证。决定扩容的关键指标包括：
- 同时运行的 Agent 任务数；
- 单任务平均模型调用次数和耗时；
- 上下文大小；
- 外部连接器延迟；
- 队列等待时间；
- 数据库慢查询；
- 每租户高峰发送量。

### 18.3 多租户公平性
- 每租户并发上限；
- 每用户短时限流；
- 交互任务优先于批处理；
- 对外发送与内部分析分队列；
- 大任务分片并设置最大执行时间；
- 单租户异常不能占满全部 Worker；
- 额度不足时给出明确提示，不把失败伪装成模型无回答。

---

## 19\. 可靠性、安全与日本合规准备

### 19.1 可靠性
- 所有写入和外部动作使用幂等键；
- 页面、消息和关键记录使用乐观锁或版本号；
- 模型调用可以重试，业务写入不能盲目重试；
- 外部系统超时后先查询状态，再决定是否补偿；
- 发送失败、预约冲突和发布失败保留人工处理入口；
- AI 不可用时，原有确定性页面与业务流程继续工作。

### 19.2 数据与隐私
- AI 只获得完成当前任务所需的最少数据；
- 跨项目数据不得进入提示、检索结果或日志；
- 联系方式、家庭和财务相关字段按角色脱敏；
- 原始行为数据、AI 工作记录和业务审计分开存储；
- 外部模型的数据处理区域、保留策略和训练使用政策应纳入供应商评审；
- 日本个人信息使用目的、保存期限、第三方提供和跨境处理需法务确认。

### 19.3 零容忍事件
- 跨租户或跨项目数据泄露；
- 未经授权发布或发送；
- 重复 SMS；
- 把“点击预约”显示为“预约成功”；
- 把 AI 推断显示为到访、认购、签约事实；
- 使用过期价格、优惠、合同或交付资料对外承诺；
- 审计记录无法还原实际发送版本和确认人。

---

## 20\. 分阶段实施路线

各阶段不是并列功能清单，而是有明确依赖关系：
```mermaid
flowchart LR
    P0["阶段0<br/>数据、权限、版本和行为可信"] --> P1["阶段1<br/>七类正式销售场景连续可用<br/>并接入浏览器AI"]
    P1 --> P2["阶段2<br/>SMS单客确认发送"]
    P1 --> P3["阶段3<br/>预约与权威结果连接"]
    P2 --> P4["阶段4<br/>分享记录与渠道归因"]
    P3 --> P4
    P4 --> P5["阶段5<br/>ROI与可解释评分"]
    P5 --> P6["阶段6<br/>更多渠道与规则内自动化"]

    Q0["基础未可信"] -. 禁止开放 .-> Q1["自动对外执行"]
    Q2["没有权威结果"] -. 无法可靠建设 .-> Q3["ROI与评分"]
```

### 阶段 0：数据与基础产品可信

目标：AI 读取到的对象、版本、权限和行为必须可靠。
- 验证项目数据隔离；
- 统一页面数、启用链接数和统计口径；
- 修复客户专属链接、深层链接和会话恢复；
- 统一角色叠加和页面操作权限；
- 明确客户删除、匿名化和恢复规则；
- 建立页面/素材版本与引用影响；
- 统一外部自主浏览和现场演示事件来源。

未通过该阶段，不开放自动对外执行。

### 阶段 1：七类正式销售场景与浏览器 AI

目标：先让主 PRD 和 AI PRD 定义的七类场景能够连续运行，再完成“读—理解—草稿—证据—确认—保存”的 AI 子闭环。
- 项目能够维护通用及主要客群标准方案、主题内容包、标准提问、必讲项和风险项；
- 首次咨询和首次接待能够直接选择客群标准方案，不生成接待前个体方案；
- 已有客户现场讲解能够正确记录并进入客户追踪；
- 现场能够切换客群方案或快速追加、跳过内容，并保存实际变化；
- 客户产生明确反馈或有效行为、进入追踪后，能够生成个体跟进和复访方案；
- 临时讲解能够在结束后关联、纠错或标记无效；
- 远程咨询能够查找/创建客户、选择或制作页面并取得访问地址；
- 到访后能够基于销售确认的反馈准备下一份页面；
- 客户自主访问后能够生成带依据的再次询问和资料建议；
- 购买申请和合同结果能够在外部完成后手动回写客户状态；
- 全局 AI 入口能够生成客户摘要、接待卡、纪要和页面工作草稿；
- 所有 AI 结果提供三层证据、确认、修改、驳回和审计；
- 多租户 Agent Gateway、任务中心和策略网关通过小范围功能开关试点。

### 阶段 2：SMS 单客行动闭环

目标：把 AI 建议变成一次可控制、可追踪的真实行动。
- 先完成 PRD 变更；
- 通信同意和退订；
- 日文 SMS 草稿；
- 单客户逐次确认发送；
- 短链、送达、失败、点击和访问回流；
- 频率、静默时段、防重复和人工接管。

### 阶段 3：预约与必要结果连接

目标：从“客户点击”连接到“权威业务结果”。
- 预约/日历系统接入；
- 暂占、确认、取消、改期和冲突处理；
- 实际到访结果回传；
- CRM 客户、负责人和必要阶段同步；
- 统一时间线和同步异常处理。

### 阶段 4：分享记录与归因

目标：回答“哪次内容、哪个渠道和哪个动作带来了结果”。
- 分享记录；
- 渠道和活动字典；
- 统一身份与事件链；
- 首次/末次触达；
- 渠道和活动漏斗；
- 数据完整率。

### 阶段 5：ROI 和可解释评分

目标：在有真实成本和结果后进行稳定测量。
- 成本和金额数据接入；
- ROI 公式与版本；
- 可解释规则评分；
- 与预约、到访和成交结果校准；
- 人工纠正和模型评测；
- 审批后的小范围规则自动化。

### 阶段 6：更多渠道和受控自动化
- LINE、邮件等连接器；
- 低风险、预授权的自动发送；
- 多触点归因；
- 企业专属策略和模型；
- 必要时为外部 Agent 提供标准 MCP/函数工具。

---

## 21\. MVP 分层定义

上一版把“首个 MVP”直接定义为客户浏览后的 SMS 行动，跳过了正式 PRD 本身的销售服务连续性。修订后采用两层 MVP，先证明业务主链能走通，再证明系统内行动能够闭环。

### 21.1 MVP-0：正式业务连续性验证

目标：使用一个已有客户、一个临时客户和一个远程咨询客户，连续覆盖主 PRD §7.1.1 的五个验收场景，并映射 AI PRD 的七类工作。

必须覆盖：
1. 项目至少配置一个通用方案和 4—5 个主要客群标准方案；
2. 首次咨询或首次到访能够选择客群标准方案，无法判断时使用通用方案，不生成接待前个体方案；
3. 现场讲解能够切换客群方案、追加或跳过内容并保存实际变化；
4. 离场后由销售确认客户明确反馈、未解决问题和是否进入追踪；
5. 客户进入追踪后，AI 才根据可靠事实生成个体跟进、页面或复访方案；
6. 临时客户先讲解，后创建/选择客户并关联，包含一次关联纠错或无效记录处理；
7. 根据现场反馈或远程咨询选择/制作页面、发布并取得客户访问地址；
8. 明确验证“复制地址不等于实际发送，未打开不产生访问记录”；
9. 客户在独立浏览器中完成身份识别和自主访问；
10. 现场讲解与自主访问在客户追踪中并列但不合并；
11. 销售根据可靠访问再次准备页面，旧页面版本和旧访问明细不被覆盖；
12. 外部完成购买申请或合同后，销售依据明确结果手动更新为中间状态、签约或未签约；
13. 页面、讲解和浏览行为不能自动修改客户状态；
14. 全过程遵守租户、项目、角色、版本和审计规则。

### 21.2 MVP-1：AI 与 SMS 行动扩展

在 MVP-0 通过后，选择一个高频场景验证：
> **客户再次浏览或现场接待结束后，AI 根据可靠依据准备下一份页面和日文 SMS；销售确认后由 Link 发送；系统记录受理、送达、失败、点击和再次访问，再回到下一轮推荐或接待准备。**   

必须具备：
1. AI 结论显示依据、来源和资料版本；
2. AI 只生成草稿，不直接发送；
3. 销售能编辑、确认或驳回；
4. 通信同意、退订、频率和静默时段有效；
5. 消息、客户、页面版本、短链、渠道和确认人绑定；
6. 受理、送达、失败、点击和访问进入时间线；
7. 重复点击确认不会重复发送；
8. AI 或 SMS 不可用时，销售仍能取得访问地址并使用外部通道完成基本工作。

### 21.3 两层 MVP 都明确不做
- 群发营销平台；
- 完整销售任务系统；
- 预约、贷款、合同和交易流程；
- 正式 ROI；
- 黑箱成交概率；
- C 端开放式 AI 聊天；
- 无边界自动执行。

---

## 22\. 验收指标

### 22.1 产品与操作

| 指标 | 建议目标 |
|------|------------|
| 常规高频操作 | 不超过 3 次主要点击 |
| 确认一次 AI 草稿 | 不超过 30 秒，复杂内容除外 |
| 客户基础信息重复填写 | 0 次 |
| AI 重要结论可查看依据 | 100% |
| 可从依据跳到原始记录 | 100% |
| 事实、判断、建议区分 | 100% |

### 22.2 AI 质量
- 首次接触使用预设客群方案的覆盖率；
- 无足够依据时正确回退通用方案的比例；
- 客户进入追踪后个体方案的采纳率；
- 接待准备草稿采纳率；
- 用户平均修改幅度；
- 关键条件提取准确率；
- 过期资料引用率；
- 无证据结论率；
- AI 被纠正的原因分布；
- 相同输入在模型切换后的结构一致性。

### 22.3 行动与业务
- 七类销售场景连续通过率；
- 首次接触使用客群标准方案的比例；
- 客群标准方案与现场实际展示差异的可追溯率；
- 离场后在规定时间内完成事实确认并进入追踪的比例；
- 临时讲解在规定时间内完成关联、纠错或无效处理的比例；
- 复制访问地址与实际发送事件的区分准确率；
- 现场讲解与客户自主访问混记率必须为 0；
- 到访后页面准备完成率和从接待结束到可发送页面的时间；
- 客户自主访问后再次推荐的采纳率；
- 客户状态变更具有明确人工或权威外部依据的比例；
- SMS 发送成功、送达、失败和退订率；
- 重复发送率必须为 0；
- 短链点击与后续有效访问率；
- 预约意向到权威确认的转化；
- 未解决问题关闭率；
- 再次来访时准备卡使用率；
- 归因数据完整率；
- ROI 可计算记录覆盖率。

### 22.4 系统
- 跨租户/跨项目泄露为 0；
- 越权工具调用成功为 0；
- 浏览器刷新后的任务恢复率；
- 队列等待时间 P50/P95；
- 模型与连接器失败降级率；
- 每租户、功能和模型的成本可追踪率 100%。

---

## 23\. PRD 变更清单

正式 PRD 已有七类销售场景，但对象和扩展结果仍需要进一步落到可开发规则。在 SMS、预约、归因、ROI 和评分进入研发前，至少补充：
1. 将七类销售场景与五个连续验收场景建立固定映射，避免设计和测试各用一套流程；
2. 明确已有客户、临时客户和远程咨询三个入口及允许的客户建档时点；
3. 明确临时讲解的未关联、关联、关联纠错和无效状态；
4. 明确地址复制、二维码展示、页面与客户关联、外部实际发送和 Link 原生发送是五种不同事件；
5. 自主浏览与现场演示的来源字段、统计口径和并列时间线；
6. 项目级客群标准方案、通用方案、主题内容包、标准提问、必讲项、风险项、维护权限和版本规则；
7. 首次客群方案选择、现场变化、进入追踪条件和追踪后个体方案的数据模型及审计；
8. 客户条件、条件历史、接待准备快照、接待场次、客户反馈和未解决问题等对象；
9. 购买申请与合同结果的外部来源、人工确认、客户状态回写和禁止推断规则；
10. 分享记录、渠道、活动和实际发送事件；
11. 通信同意、退订、频率和静默时段；
12. SMS 草稿、确认、发送和回执状态机；
13. 预约意向、暂占、确认、取消、到访状态机；
14. 外部系统的主数据、同步方向和冲突规则；
15. 归因事件链、时间窗和规则版本；
16. ROI 成本、金额、币种、周期和公式口径；
17. 评分特征、解释、衰减、校准和纠正；
18. 工具风险级别、确认规则和预授权范围；
19. 多租户、项目、对象级权限；
20. 审计、保留、删除和合规规则；
21. 各阶段验收指标和明确不做范围。

---

## 24\. 开发前必须确认的业务决策
1. 是否正式采用“七类销售工作、五个连续验收场景、三个业务入口”的统一口径；
2. 是否采用“客群标准方案 → 首次接触直接使用 → 现场适配 → 进入追踪后个体化”的机制；
3. 第一批客群方案采用哪些需求导向分类，由营销企划、销售经理还是内容运营维护；
4. 客户满足什么条件后进入追踪并允许生成个体方案；
5. 哪些内容属于不可删除的必讲项，哪些价格、贷款、交付和合同信息必须转交专业人员；
6. MVP-0 是否先于 Link 原生 SMS 上线并完成企业试用验收；
7. 首个试点项目、真实用户规模，以及已有/临时/远程三类样本各准备多少；
8. 当前正式范围中的外部发送工具需要记录到什么程度，谁负责确认“实际已发送”；
9. 第一系统内发送渠道是否确定为 SMS，供应商是谁；
10. 日本市场通信同意、退订和静默时段规则；
11. 客户、负责人、预约、到访、成交和金额各自的权威系统；
12. Link 是保存业务结果副本，还是仅保存外部引用；
13. 当前项目允许的 AI 数据范围；
14. 高风险信息的审核人和替代人员；
15. 哪些动作首期逐次确认，哪些未来可以预授权；
16. 分享渠道和活动字典由谁维护；
17. ROI 采用收入、毛利还是其他业务价值口径；
18. 评分的用途是排序、提醒还是自动触发；
19. 企业客户是否需要自带模型 Key 或专属部署。

---

## 25\. 竞品与技术参考链接

### 25.1 日本竞品企业
- KASIKA：[Cocolive](https://cocolive.co.jp/)、[主要功能](https://cocolive.co.jp/key-features/)、[2026—2027 路线图](https://prtimes.jp/main/html/rd/p/000000056.000025942.html)、[AI 推荐](https://prtimes.jp/main/html/rd/p/000000049.000025942.html)、[客户 MyPage](https://prtimes.jp/main/html/rd/p/000000051.000025942.html)
- ROOV：[STYLE PORT](https://styleport.co.jp/)、[新建公寓方案](https://styleport.co.jp/roov/for-mansion/)
- Digima：[企业信息](https://digima.com/company)、[产品官网](https://digima.com/)、[AI Agent 发布](https://prtimes.jp/main/html/rd/p/000000008.000002312.html)
- Facilo：[企业信息](https://www.facilo.jp/company/)、[产品官网](https://www.facilo.jp/)
- ITANDI：[企业官网](https://corp.itandi.co.jp/)、[服务动态](https://service.itandi.co.jp/news/260714)
- Musubell：[产品官网](https://www.musubell.com/)、[新建公寓方案](https://www.musubell.com/new-const/)
- いえらぶ：[集团](https://www.ielove-group.jp/)、[いえらぶ CLOUD](https://ielove-cloud.jp/service/)
- いい生活：[企业信息](https://www.e-seikatsu.info/aboutUs/profile.html)、[AI-native 平台 IR](https://www2.jpx.co.jp/disc/37960/140120260514532650.pdf)
- LIFULL：[企业信息](https://lifull.com/company/about/)、[LIFULL AI](https://lifull.com/news/45744/)

### 25.2 Agent 官方文档总入口
- OpenAI：[Responses API](https://developers.openai.com/api/reference/cli/resources/responses/methods/create)、[Function calling](https://developers.openai.com/api/docs/guides/function-calling)、[Structured Outputs](https://developers.openai.com/api/docs/guides/structured-outputs)、[File search](https://developers.openai.com/api/docs/guides/tools-file-search)、[MCP and Connectors](https://developers.openai.com/api/docs/guides/tools-connectors-mcp)、[Background mode](https://developers.openai.com/api/docs/guides/background)、[Data controls](https://developers.openai.com/api/docs/guides/your-data)、[Rate limits](https://developers.openai.com/api/docs/guides/rate-limits)、[Cost optimization](https://developers.openai.com/api/docs/guides/cost-optimization)、[Safety best practices](https://developers.openai.com/api/docs/guides/safety-best-practices)。具体对应关系见 §15。
- DeepSeek API：[快速开始](https://api-docs.deepseek.com/)、[Tool Calls](https://api-docs.deepseek.com/guides/tool_calls)、[JSON Output](https://api-docs.deepseek.com/guides/json_mode/)、[Thinking Mode](https://api-docs.deepseek.com/guides/thinking_mode)、[Context Caching](https://api-docs.deepseek.com/guides/kv_cache/)、[Rate Limit & Isolation](https://api-docs.deepseek.com/quick_start/rate_limit/)。具体对应关系见 §16。
- DeepSeek Harness：[产品页](https://www.deepseek.com/harness/)、[官方文档](https://deepseek-harness.github.io/deepseek-harness/en/guide/quickstart)、[架构](https://github.com/deepseek-ai/deepseek-harness/blob/master/docs/architecture.md)、[Python SDK](https://github.com/deepseek-ai/deepseek-harness/blob/master/python/sdk/README.md)、[数据处理说明](https://www.deepseek.com/harness/data-processing/)、[Safe Use Policy](https://www.deepseek.com/harness/en/privacy/)。具体对应关系见 §16。

---

## 26\. 最终建议

本项目不应在“只做内容链接”和“一次性建设完整 AI CRM”之间二选一。最合理的路径是：
1. **以正式 PRD 为底座**，先保证内容、页面、客户、权限、版本和访问行为可信；
2. **先建设房地产销售的客群标准方案**，按主要购房需求准备通用及 4—5 个客群内容路径，不让首次接待从零准备；
3. **首次接触不做个体 AI 定制**：销售直接选择客群标准方案，现场按真实反馈适配，客户进入追踪后才生成个体跟进与复访方案；
4. **采用日本销售场景文档的服务连续性设计**，让 AI 围绕接待前、接待后和信息变化工作；
5. **采用轻量化方案的交互原则**，把 AI 放进现有客户、页面和任务流程，不增加大量菜单和表单；
6. **采用 SMS 行动方案作为第一个执行扩展**，但必须先修改 PRD，并从单客、人工确认开始；
7. **采用四项薄弱能力文档的建设依赖**：先有动作与结果，再有归因，最后才有 ROI 和评分；
8. **采用竞品报告的防守策略**，守住专业内容、客户空间、行为语义和可确认 AI 草稿，把 CRM 与交易能力通过接口连接；
9. **采用浏览器多租户技术方案**，让 Agent 只通过强类型工具受控执行，绝不直接写数据库；
10. **拒绝当前阶段的重型扩张**：完整 CRM、完整交易、黑箱成交概率、开放式 C 端 AI 和无边界自动发送。

最终形成的产品闭环应当是：
> **项目先维护客群标准方案和专业内容 → 首次接触直接使用标准方案 → 销售现场适配并记录事实 → 客户进入追踪后 AI 生成个体跟进/复访方案 → 新行为与权威结果持续更新个体方案。**